I'm working on filling in an Rd file for a function.
When I use \eqn{2^{x}} in the Details section, then build and install the package, there is no superscripted exponent.
Looking at R-exts.pdf, it points to Poisson.Rd as an example on how to use \eqn or \deqn. In the example in that file, there is a superscripted exponent.
When I look at the help file for Poisson (?Poisson), There are no superscripted exponents.
Is this an issue on my computer or is this standard behavior?
Thanks!
> sessionInfo()
R version 2.11.1 (2010-05-31)
i386-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] cimis_0.1-3 RLastFM_0.1-4 RCurl_1.4-2 bitops_1.0-4.1 XML_3.1-0 lattice_0.18-8
loaded via a namespace (and not attached):
[1] grid_2.11.1 tools_2.11.1
Nowadays, people mainly use the HTML help.
To get the superscript in the HTML help as well as in the PDF help, do:
\ifelse{html}{\out{2<sup>x</sup>}}{\eqn{2^x}}
The syntax is:
\ifelse{html}{\out{HTML CODE}}{\eqn{LATEX-LIKE CODE}{ASCII}}
with {ASCII} optional.
You don't say where you looked to see if there was a superscripted exponent. I presume the text based help, not the PDF version of the manual?
The syntax for the \eqn macro is \eqn{latex}{ascii}. The {ascii} bit is optional, in which case R will do it's best to render the LaTeX version. Conventionally, subscripts in ASCII would be wrapped in [] and superscipts with ^.
So I would write:
\eqn{2^{x}}{2^x}
But in all practical senses these are the same. The issue is just that the text help can't display superscipts, but the PDF can.
Related
I can't seem to display greek letters in r. I'm working with RStudio, and I can't seem to display greek characters no matter what I try. Initially I tried to display greek letters inside bquote, using syntax from a class I took, which the prof. published and demonstrated it worked in class. When all it showed was squares**, I tried more basic ways of displaying greek letters. I tried to use expression and than I tried to find the simplest way and ran this syntax which I found online:
mycoef <- rnorm (1000)
hist(mycoef, main = expression(beta))
In all cases it either display a square (like an unrecognized symbol), or just the word (beta, chi, etc.,). This syntax also displayed a square using R instead of RStudio.
I tried to change a bit the encoding of the file (ASCII/UTF-8), but this didn't change anything. I am working on a mac (macOS Sierra 10.12.4) if that changes anything.
**when using the bquote syntax, greek letters were not the only characters it changed to squares. Also == and ~~ without quotes were displayed as squares.
This is my sessionInfo() -
R version 3.4.2 (2017-09-28)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: macOS Sierra 10.12.4
Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/3.4/Resources/lib/libRlapack.dylib
locale:
[1] pt_PT.ISO8859-1/pt_PT.ISO8859-1/pt_PT.ISO8859-1/C/pt_PT.ISO8859-1/C
attached base packages:
[1] grid stats graphics grDevices utils datasets methods base
other attached packages:
[1] plyr_1.8.4 meta_4.8-4 openxlsx_4.0.17
loaded via a namespace (and not attached):
[1] compiler_3.4.2 tools_3.4.2 Rcpp_0.12.13
=====
Note that as a try to fix this problem I ran this syntax that is displayed in the sessionInfo - Sys.setlocale("LC_ALL", "pt_PT.ISO8859-1"), which didn't help.
Thanks!
You can try using package latex2exp if you know the basics of LaTeX:
library(latex2exp)
mycoef <- rnorm (1000)
hist(mycoef, main = TeX("$\\beta$"))
I solved this problem updating the Symbols Font on Windows. (1) Download the file Symbol.ttf (https://www.fontsupply.com/fonts/S/Symbol.html),
(2) Find the file symbol.ttf in your \Windows\Fonts folder, and replace with the fresh copy.
I just recently learnt about plotmath and its ability to put mathematical expression in text on plots.
However I'm encountering some strange behaviour where the substitute function does not render any text.
Here's a simple case that should work (from this answer):
labNames <- c('xLab','yLab')
plot(c(1:10),
xlab=substitute(paste(nn, x^2), list(nn=labNames[1])),
ylab=substitute(paste(nn, y^2), list(nn=labNames[2])))
When I run this code snippet, there is no xlab or ylab text.
I'm running mac osx and R 3.0.0. This problem persists whether i output to Quartz or to a png file.
Here's my sessionInfo():
R version 3.0.0 (2013-04-03)
Platform: x86_64-apple-darwin12.3.0 (64-bit)
locale:
[1] en_AU.UTF-8/en_AU.UTF-8/en_AU.UTF-8/C/en_AU.UTF-8/en_AU.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
I found the culprit: there was a weird interaction with an option in my .Rprofile
The following line causes the issue if i don't load the devtools package:
options(devtools.desc.author="'Scott Ritchie <sritchie73#gmail.com> [aut, cre]'")
Strangely, there doesn't seem to be an issue if i define other irrelevant options (options(notanoption=TRUE) caused no issues).
I am using knitr 1.1. in R 3.0.0 and within WinEdt (RWinEdt 2.0). I am having problems with knitr recognizing Swedish characters (ä, ö, å). This is not an issue with R; those characters are even recognized in file names, directory names, objects, etc. In Sweave it was not a problem either.
I already have \usepackage[utf8]{inputenc} in my document, but knitr does not seem able to handle the special characters. After running knitr, I get the following message:
Warning in remind_sweave(if (in.file) input) :
It seems you are using the Sweave-specific syntax; you may need Sweave2knitr("deskriptiv 130409.Rnw") to convert it to knitr
processing file: deskriptiv 130409.Rnw
(*) NOTE: I saw chunk options "label=läser_in_data"
please go to http://yihui.name/knitr/options (it is likely that you forgot to
quote "character" options)
Error in parse(text = str_c("alist(", quote_label(params), ")"), srcfile = NULL) :
1:15: unexpected input
1: alist(label=lä
^
Calls: knit ... parse_params -> withCallingHandlers -> eval -> parse
Execution halted
The particular label it complains about is label=läser. Changing the label is not enough, since knitr even complains if R objects use äåö.
I used Sweave2knitr() since the file originally was created for Sweave, but the result was not better: now all äåö have been transformed to äpåö, both in the R chunks and in the latex text, and knitr still gives an error message.
Session info:
R version 3.0.0 (2013-04-03)
Platform: i386-w64-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Swedish_Sweden.1252 LC_CTYPE=Swedish_Sweden.1252 LC_MONETARY=Swedish_Sweden.1252
[4] LC_NUMERIC=C LC_TIME=Swedish_Sweden.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] knitr_1.1
loaded via a namespace (and not attached):
[1] digest_0.6.3 evaluate_0.4.3 formatR_0.7 stringr_0.6.2 tools_3.0.0
As I mentioned there are file names and objects with Swedish characters (since that has not been a problem before), and also the text needs to be in Swedish.
Thank you for any help in getting knitr to work outside of English.
I think you have to contact the maintainer of the R-Sweave mode in WinEdt if you are using this mode to call knitr. The issue is WinEdt has to pass the encoding of the file to knit() if you are not using the native encoding of your OS. You mentioned UTF-8 but that is not the native encoding for Windows, so you must not use \usepackage[utf8]{inputenc} unless you are sure your file is UTF8-encoded.
There are several problems mixed up here, and it is unlikely to solve them all with a single answer.
The first problem is label=läser, which really should be label='läser', i.e. you must quote all the chunk labels (check other labels in the document as well); knitr tries to automatically quote your labels when you write <<foo>>= (it is turned to <<'foo'>>=), but this does not work when you use <<label=foo>>= (you have to write <<label='foo'>>= explicitly). But this problem is perhaps not essential here.
I think the real problem here is the file encoding (which is nasty under Windows). You seem to be using UTF-8 under a system that does not respect UTF-8 by default. In this case you have call knit('yourfile.Rnw', encoding = 'UTF-8'), i.e. pass the encoding to knit(). I do not use WinEdt, so I have no idea how to do that. You can hard-code the encoding in the configurations, but that is not recommended.
Two suggestions:
do not use UTF-8 under Windows; use your system native encoding (Windows-1252, I guess) instead;
or use RStudio instead of WinEdt, which can pass the encoding to knitr;
BTW, since Sweave2knitr() was popped up, there must be other problems in your Rnw document. To diagnose the problem, there are two ways to go:
if you use UTF-8, run Sweave2knitr('deskriptiv 130409.Rnw', encoding = 'UTF-8')
if you use the native encoding of your OS, just run Sweave2knitr('deskriptiv 130409.Rnw')
Please read the documentation if you have questions about the diagnostic information printed out by Sweave2knitr().
R-Sweave invokes knitr through the knitr.edt macro, which itself uses the code in knitrSweave.R to launch knit. The knitcommand in this later script is near the top and reads res <- knit(filename).
Following Yihui's suggestion, you can try to replace this command with
res <- knit(filename, encoding = 'UTF-8')
The knitr.edt and knitrSweave.R files should be in your %b\Contrib\R-Sweave folder, where %b is your winEdt user folder (something like "C:\Users\userA\AppData\Roaming\WinEdt Team\WinEdt 7" under Win 7).
Currently, I do not know how we could pass the encoding as an argument to avoid this hard coding solution.
I would suggest to avoid extended characters in file names which can only be sources of problems. Personally, I never use such names.
I had this weird encoding issue for my Emacs and R environment. Display of Chinese characters are all good with my .Rprofile setting Sys.setlocale("LC_ALL","zh_CN.utf-8"); except the echo of input ones.
> linkTexts[5]
font
"使用帮助"
> functionNotExist()
错误: 没有"functionNotExist"这个函数
> fire <- "你好"
> fire
[1] " "
As we can see, Chinese characters contained in the vector linkTexts, Chinese error messages, and input Chinese characters all can be perfectly shown, yet the echo of input characters were only shown as blank placeholders.
sessionInfo() is here, which is as expected given the Sys.setlocale("LC_ALL","zh_CN.utf-8"); setting:
> sessionInfo()
R version 2.15.2 (2012-10-26)
Platform: i386-apple-darwin9.8.0/i386 (32-bit)
locale:
[1] zh_CN.utf-8/zh_CN.utf-8/zh_CN.utf-8/C/zh_CN.utf-8/C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] XML_3.96-1.1
loaded via a namespace (and not attached):
[1] compiler_2.15.2 tools_2.15.2
And I have no locale settings in the .Emacs file.
To me, this seems to be an Emacs encoding issue, but I just don't know how to correct it. Any idea or suggestion? Thanks.
Your examples work for me out of the box. You can set emacs process decoding/encoding with M-x set-buffer-process-coding-system. Once you figure out what encoding works (if any) you can make the change permanent with:
(add-hook 'ess-R-post-run-hook
(lambda () (set-buffer-process-coding-system
'utf-8-unix 'utf-8-unix)))
Replace utf-8-unix with your chosen encoding.
I am not very convinced that the above will help. LinkText in your example displays well, but fire does not, doesn't look like an emacs/ESS issue.
VitoshKa has made the perfectly correct suggestion. I just wanna add more of own findings here, as people may meet different but similar special character problems. Yet they can be solved in the same way.
The root cause is the input encoding setting to the current buffer process. As shown by the M-x describe-current-coding-system command, default buffer process encoding setting was good for output (utf-8-unix) but deteriorated for input:
Coding systems for process I/O:
encoding input to the process: 1 -- iso-latin-1-unix (alias: iso-8859-1-unix latin-1-unix)
decoding output from the process: U -- utf-8-unix (alias: mule-utf-8-unix)
Changing the coding system for input into utf-8-unix， either by 'M-x set-buffer-process-coding-system' or adding the ess-post-run-hook into .emacs like suggested by VitoshKa, would suffice for solving the Chinese character display problem.
The other problem people may meet due to this setting is special character in ESS. When trying to input special characters, you may get the error message, 错误: 句法分析器%d行里不能有多字节字符
, or invalid multibyte character in parser at line %d in English.
> x <- data.frame(part = c("målløs", "ny"))
错误: 句法分析器1行里不能有多字节字符
And with the correct utf-8-unix setting for input coding system of buffer process, the above error for special characters disappears.
I'm trying to use the function regmatches, in R, but i'm getting an error (R says it can't find the function).
I'm quite tired now and maybe I'm doing some really silly mistake. However, I don't know what's wrong.
I tried to use ??regmatches, but it didn't find anything.
Next I tried the "sos" package and function findFn("regmatches"), but it returned:
found 0 matches
x has zero rows; nothing to display.
Mensagens de aviso perdidas:
In findFn("regmatches") : HIT not found in HTML; processing one page only.
I don't know what else to do.
I know I may be doing a silly mistake like this one, but I don't know what else to do. Below is my session info:
R version 2.12.2 (2011-02-25)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
1 LC_COLLATE=Portuguese_Brazil.1252 LC_CTYPE=Portuguese_Brazil.1252
[3] LC_MONETARY=Portuguese_Brazil.1252 LC_NUMERIC=C
[5] LC_TIME=Portuguese_Brazil.1252
attached base packages:
1 stats graphics grDevices utils datasets methods base
other attached packages:
1 sos_1.3-1 brew_1.0-6
loaded via a namespace (and not attached):
1 tools_2.12.2
regmatches was added in R 2.14.0...
I'm sorry guys. It happens that is was a silly mistake. After almost giving up, I decided to check if it was a problem with my version of R. So, I took a look at the CRAN webpage and found this under what's new with R 2.14.
New function regmatches() for extracting or replacing matched or non-matched substrings from match data obtained by regexpr(), gregexpr() and regexec().
So, It's time to update R. I thought that using version 2.12.2 wasn't that bad, but it happens it was.