Re: [Rd] plotmath indices: suggested addition to help file
Thank you, Claudia,
> "CB" == Claudia Beleites
> on Thu, 20 Jan 2011 14:05:41 +0100 writes:
CB> Dear all, I just stumbled over the fact that subsetting
CB> by square bracket will only output the first given
CB> index. I guess the rest is thrown away by the CADDR in
CB> RenderSub (plotmath.c l. 1399). Maybe changing this
CB> could be considered as "low-priority desired" (would be
CB> nice if the output works for ?
I agree this is a ``missing feature'' and well worth wish list item.
CB> However, I suggest to announce the fact that only the
CB> first parameter is printed in plotmath.Rd.
CB> E.g. in the table l. 72
CB> \code{x[i]} \tab x subscript i; escape further indices (\code{x ["i,
j"]})\cr
How would get the equivalent of LaTeX x_{i_1, j_2} ?
Not by making it a string (that's not escape, I'd say),
but by something like
plot(0, axes=FALSE, main= expression(paste(x[i[1]],{}[j[2]])))
which works +-
but of course is unnecessarily ugly, compared to the desired
plot(0, axes=FALSE, main= expression( x[i[1], j[2]]))
Martin
CB> Claudia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setGeneric for residuals, etc
> -Ursprüngliche Nachricht-
> Von: r-devel-boun...@r-project.org [mailto:r-devel-bounces@r-
> project.org] Im Auftrag von Johann Hibschman
> Gesendet: Donnerstag, 20. Januar 2011 16:25
> An: r-de...@stat.math.ethz.ch
> Betreff: [Rd] setGeneric for residuals, etc
>
> I'm experimenting with a few model-fitting classes of my own. I'm
> leaning towards using S4 for my classes, but the R functions I'd want
> to
> override (residuals, predict, etc.) are all S3 methods.
>
> As I understand it, I could do setGeneric("residuals"), then add S4
> specializations to it. However, I don't understand the full
> consequences of doing this. Are there any drawbacks? Is there some
> code that will not run properly if I do this? It feels like I'm
> reaching in and modifying a core R function, which makes me nervous.
>
> To put it another way, if it's completely transparent and causes no
> problems, why isn't it done by default?
>
> (If it matters, I'm still on 2.10.1, but I can take it up with global
> architecture if there are compelling changes in later versions.)
>
> Thanks,
> Johann
>
Well, one "drawback" with S4 is that you need to write more explicit code
than in a pure S3 world, but it makes your code also a lot more robust
(method dispatch, validation etc.). As far as I understand it, working with
customized S4 objects would imply that you need to specify methods for all
those S3 functions already out there that you want to work with your
objects. For example, inside your method for 'residuals()', you will
probably just get some data out of a slot of your object and run the S3
function 'residuals(your.slot.data)'. So there's nothing that should make
you nervous in that respect, you're not overwriting anything with your
method. Setting a generic for an existing function is just a necessary step
in order to specify S4 methods for it.
However, you could also write a couple methods that coerce your custom
object into those S3 objects that the already implemented functions expect
(e.g. 'residuals()'). Another drawback might be efficiency depending on how
complex your S4 objects are (e.g. how many nested function calls are
required to get to actual data).
HTH,
Janko
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Calling C++ from R
Hi All,
I am new to this area and use Rcpp to call C++ from R and try to build the
package under Windows 7. I use Rtools and R 2.10.1 32bit. Everything works
fine with me, except using R functions like "rnorm" or "runif" in the C++
code. When I use "R CMD check" the package, it always return error
** libs
making DLL ...
g++ -I"c:/PROGRA~2/R/R-210~1.1/include"
-I"c:/PROGRA~2/R/R-210~1.1/library/Rcpp/include" -O2 -Wall -c func.cpp
-o func.o
func.cpp: In function 'SEXPREC* myfunction(SEXPREC*, SEXPREC*)':
func.cpp:220: error: 'rgamma' was not declared in this scope
func.cpp:225: error: 'rnorm' was not declared in this scope
func.cpp:244: error: 'runif' was not declared in this scope
func.cpp:274: error: 'rbeta' was not declared in this scope
make: *** [func.o] Error 1
... done
although I already put , and in the header file.
//
The func.cpp file has the following structure
#include "func.h"
SEXP myfunction(SEXP a, SEXP b) {
}
//
The header file "func.h" has the following content
#include
#include
#include
#include
#include
RcppExport SEXP myfunction(SEXP a, SEXP b);
/
What could the problem be?
Many thanks,
Xiaochun
--
View this message in context:
http://r.789695.n4.nabble.com/Calling-C-from-R-tp3228490p3228490.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] match function causing bad performance when using table function on factors with multibyte characters on Windows
[I originally posted this on the R-help mailing list, and it was suggested that
R-devel would be a better
place to dicuss it.]
Running ‘table’ on a factor with levels containing non-ASCII characters
seems to result in extremely bad performance on Windows. Here’s a simple
example with benchmark results (I’ve reduced the number of replications to
make the function finish within reasonable time):
library(rbenchmark)
x.num=sample(1:2, 10^5, replace=TRUE)
x.fac.ascii=factor(x.num, levels=1:2, labels=c("A","B"))
x.fac.nascii=factor(x.num, levels=1:2, labels=c("Æ","Ø"))
benchmark( table(x.num), table(x.fac.ascii), table(x.fac.nascii),
table(unclass(x.fac.nascii)), replications=20 )
test replications elapsed relative user.self
sys.self user.child sys.child
4 table(unclass(x.fac.nascii)) 201.53 4.636364 1.51
0.01 NANA
2 table(x.fac.ascii) 200.33 1.00 0.33
0.00 NANA
3 table(x.fac.nascii) 20 146.67 444.454545 38.52
81.74 NANA
1 table(x.num) 201.55 4.696970 1.53
0.01 NANA
sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=Norwegian-Nynorsk_Norway.1252
LC_CTYPE=Norwegian-Nynorsk_Norway.1252
LC_MONETARY=Norwegian-Nynorsk_Norway.1252
[4] LC_NUMERIC=C
LC_TIME=Norwegian-Nynorsk_Norway.1252
attached base packages:
[1] stats graphics grDevices datasets utils methods base
other attached packages:
[1] rbenchmark_0.3
The timings are from R 2.12.1, but I also get comparable results
on the latest prelease (R 2.13.0 2011-01-18 r54032).
Running the same test (100 replications) on a Linux system with
R.12.1 Patched results in essentially no difference between the
performance on ASCII factors and non-ASCII factors:
test replications elapsed relative user.self
sys.self user.child sys.child
4 table(unclass(x.fac.nascii)) 100 4.607 3.096102 4.455
0.092 0 0
2 table(x.fac.ascii) 100 1.488 1.00 1.459
0.028 0 0
3 table(x.fac.nascii) 100 1.616 1.086022 1.560
0.051 0 0
1 table(x.num) 100 4.504 3.026882 4.403
0.079 0 0
sessionInfo()
R version 2.12.1 Patched (2011-01-18 r54033)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=nn_NO.UTF-8 LC_NUMERIC=C
LC_TIME=nn_NO.UTF-8
[4] LC_COLLATE=nn_NO.UTF-8 LC_MONETARY=C
LC_MESSAGES=nn_NO.UTF-8
[7] LC_PAPER=nn_NO.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=nn_NO.UTF-8
LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rbenchmark_0.3
Profiling the ‘table’ function indicates almost all the time if spent in
the ‘match’ function, which is used when ‘factor’ is used on a ‘factor’
inside ‘table’. Indeed, ‘x.fac.nascii = factor(x.fac.nascii)’ by itself
is extremely slow.
Is there any theoretical reason ‘factor’ on ‘factor’ with non-ASCII
characters must be so slow? And why doesn’t this happen on Linux?
Perhaps a fix for ‘table’ might be calculating the ‘table’ statistics
*including* all levels (not using the ‘factor’ function anywhere),
and then removing the ‘exclude’ levels in the end. For example,
something along these lines:
res = table.modified.to.not.use.factor(...)
ind = lapply(dimnames(res), function(x) !(x %in% exclude))
do.call("[", c(list(res), ind, drop=FALSE))
(I haven’t tested this very much, so there may be issues with this
way of doing things.)
--
Karl Ove Hufthammer
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] table on numeric vector with exclude argument containing value missing from vector causes warning + "NaN" levels incorrectly removed from factors
I *think* the following may be considered a bug or two, but would appreciate
any comments before (not) filing an official bug report.
Possible bug 1: ‘table’ on numeric vector with ‘exclude’ argument containing
value missing from vector causes warning
Possible bug 2: ‘table’ incorrectly tries to remove "NaN" levels
The help page for ‘table’ says the the first argument is ‘one or more
objects which can be interpreted as factors (including character strings)
[…]’. Does this include numeric vectors? Numeric vectors seems to work fine.
Example:
x = sample(1:3, 100, replace=TRUE)
table(x)
The ‘exclude’ argument explicitly mentions factor levels, but seems to work
fine for other objects too. Example:
table(x, exclude=2)
It’s actually not clear from the help page what is meant by ‘levels to
remove from all factors in ...’, but it seems like a character vector is
expected. And indeed the following also works:
table(x, exclude="2")
However, setting the ‘exclude’ argument to a value not contained in
the vector to be tabulated,
table(x, exclude="foo")
causes the following warning:
In as.vector(exclude, typeof(x)) : NAs introduced by coercion’:
The correct results is produced, though. Note that all of the following does
*not* cause any warning:
table(x, exclude=NA)
table(x, exclude=NaN)
table(factor(x), exclude="foo")
table(as.character(x), exclude="foo")
I also wonder about the inclusion of ‘NaN’ in the definition of ‘table’:
table(..., exclude = if (useNA == "no") c(NA, NaN), useNA = c("no",
"ifany", "always"), dnn = list.names(...), deparse.level = 1)
A factor can’t include a NaN level, as the levels values are always
strings or NA. And having the above definition causes "NaN" (string)
levels to mysteriously disappear when run through ‘table’. Example:
table(factor(c("NA",NA,"NcN","NbN", "NaN")))
Result:
NA NbN NcN
1 1 1
(The missing NA is not a bug; it’s caused by useNA="no".)
sessionInfo()
R version 2.12.1 Patched (2011-01-20 r54056)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Karl Ove Hufthammer
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Calling C++ from R
It is more effective to send such inquiries to the Rcpp-devel mailing
list which I am cc'ing on this reply.
On Thu, Jan 20, 2011 at 3:05 PM, mtck1982 wrote:
>
> Hi All,
>
> I am new to this area and use Rcpp to call C++ from R and try to build the
> package under Windows 7. I use Rtools and R 2.10.1 32bit. Everything works
> fine with me, except using R functions like "rnorm" or "runif" in the C++
> code. When I use "R CMD check" the package, it always return error
>
> ** libs
> making DLL ...
> g++ -I"c:/PROGRA~2/R/R-210~1.1/include"
> -I"c:/PROGRA~2/R/R-210~1.1/library/Rcpp/include" -O2 -Wall -c func.cpp
> -o func.o
> func.cpp: In function 'SEXPREC* myfunction(SEXPREC*, SEXPREC*)':
> func.cpp:220: error: 'rgamma' was not declared in this scope
> func.cpp:225: error: 'rnorm' was not declared in this scope
> func.cpp:244: error: 'runif' was not declared in this scope
> func.cpp:274: error: 'rbeta' was not declared in this scope
> make: *** [func.o] Error 1
> ... don
It is not clear if you are trying to use the Rcpp "sugar"
constructions, which can apply to entire vectors, of if you are using
the functions in the R API. If the latter then you will need to
preface the name with Rf_, as in Rf_runif. Those are the actual names
of the functions. The Rinternals.h file defines a number of aliases,
such as runif, but in Rcpp those aliases are turned off, so as to
avoid name clashes.
You should note that when calling random number generator functions
the programmer is responsible for getting and restoring the seed
structure. I can't remember the details right now and I am on a
Windows system without the sources so I will rely on someone else to
fill in the details.
> although I already put , and in the header file.
> //
> The func.cpp file has the following structure
>
> #include "func.h"
> SEXP myfunction(SEXP a, SEXP b) {
> }
> //
> The header file "func.h" has the following content
>
> #include
> #include
> #include
> #include
> #include
> RcppExport SEXP myfunction(SEXP a, SEXP b);
> /
> What could the problem be?
>
> Many thanks,
> Xiaochun
> --
> View this message in context:
> http://r.789695.n4.nabble.com/Calling-C-from-R-tp3228490p3228490.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Rcpp-devel] Calling C++ from R
On 21 January 2011 at 06:44, Douglas Bates wrote: | It is more effective to send such inquiries to the Rcpp-devel mailing | list which I am cc'ing on this reply. Correct. | On Thu, Jan 20, 2011 at 3:05 PM, mtck1982 wrote: | > | > Hi All, | > | > I am new to this area and use Rcpp to call C++ from R and try to build the | > package under Windows 7. I use Rtools and R 2.10.1 32bit. Everything works | > fine with me, except using R functions like "rnorm" or "runif" in the C++ | > code. When I use "R CMD check" the package, it always return error | > | > ** libs | > making DLL ... | > g++ -I"c:/PROGRA~2/R/R-210~1.1/include" | > -I"c:/PROGRA~2/R/R-210~1.1/library/Rcpp/include" -O2 -Wall -c func.cpp | > -o func.o | > func.cpp: In function 'SEXPREC* myfunction(SEXPREC*, SEXPREC*)': | > func.cpp:220: error: 'rgamma' was not declared in this scope | > func.cpp:225: error: 'rnorm' was not declared in this scope | > func.cpp:244: error: 'runif' was not declared in this scope | > func.cpp:274: error: 'rbeta' was not declared in this scope | > make: *** [func.o] Error 1 | > ... don | | It is not clear if you are trying to use the Rcpp "sugar" | constructions, which can apply to entire vectors, of if you are using | the functions in the R API. If the latter then you will need to | preface the name with Rf_, as in Rf_runif. Those are the actual names | of the functions. The Rinternals.h file defines a number of aliases, | such as runif, but in Rcpp those aliases are turned off, so as to | avoid name clashes. | | You should note that when calling random number generator functions | the programmer is responsible for getting and restoring the seed | structure. I can't remember the details right now and I am on a | Windows system without the sources so I will rely on someone else to | fill in the details. The easiest is to just declared a variable of type Rcpp::RNGScope which saves state when entering the local scope (ie "set of curly braces") and restores it when leaving, thanks to what one can do with C++. Here is an example Romain wrote to the rcpp-devel list in October: In addition, we have the RNGScope class, whose constructor calls=20 GetRNGstate and destruvctor calls PutRNGstate, so that you can do : fx <- cxxfunction( , ' RNGScope scope ; NumericVector x = rgamma( 10, 1, 1 ) ; return x ; ', plugin="Rcpp" ) fx() That's self-contained example for inline, using the rgamma sugar function. You need the Rcpp:: prefix or a 'using namespace Rcpp;' when you use that in your own source code. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath indices: suggested addition to help file
On 2011-01-21 02:27, Martin Maechler wrote:
Thank you, Claudia,
"CB" == Claudia Beleites
on Thu, 20 Jan 2011 14:05:41 +0100 writes:
CB> Dear all, I just stumbled over the fact that subsetting
CB> by square bracket will only output the first given
CB> index. I guess the rest is thrown away by the CADDR in
CB> RenderSub (plotmath.c l. 1399). Maybe changing this
CB> could be considered as "low-priority desired" (would be
CB> nice if the output works for ?
I agree this is a ``missing feature'' and well worth wish list item.
CB> However, I suggest to announce the fact that only the
CB> first parameter is printed in plotmath.Rd.
CB> E.g. in the table l. 72
CB> \code{x[i]} \tab x subscript i; escape further indices (\code{x ["i,
j"]})\cr
How would get the equivalent of LaTeX x_{i_1, j_2} ?
Not by making it a string (that's not escape, I'd say),
but by something like
plot(0, axes=FALSE, main= expression(paste(x[i[1]],{}[j[2]])))
which works +-
but of course is unnecessarily ugly, compared to the desired
plot(0, axes=FALSE, main= expression( x[i[1], j[2]]))
I don't know if I've ever disagreed with Martin's advice but,
unless I'm missing something, Claudia wants something done about
the second index in x[i, j] while Martin is talking about the
case of cascading subscripts in 'x_sub_i_sub_1' (as shown in his
LaTeX expression).
Both situations are nicely handled with the 'list()' and '[]'
constructs in plotmath:
plot(0, axes=FALSE, main= expression( x[ list( i[1], j[2] ) ] ) )
To handle Claudia's wish, it might be desirable to have plotmath.c
automatically recognize such cases but I would consider that to
be (as Claudia says) in the 'nice if' category. Claudia's suggestion
for the help page could be handled by adding another example. Then
again, plotmath (not surprisingly) is like LaTeX in that, the more
you use it, the more you become familiar with the special constructs
needed to get the output you want. I still find myself scurrying to
?plotmath and scanning the Syntax/Meaning table quite frequently.
Peter Ehlers
Martin
CB> Claudia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath indices: suggested addition to help file
> "PE" == Peter Ehlers
> on Fri, 21 Jan 2011 06:17:20 -0800 writes:
PE> On 2011-01-21 02:27, Martin Maechler wrote:
>> Thank you, Claudia,
>>
>>> "CB" == Claudia Beleites on Thu,
>>> 20 Jan 2011 14:05:41 +0100 writes:
>>
CB> Dear all, I just stumbled over the fact that subsetting
CB> by square bracket will only output the first given
CB> index. I guess the rest is thrown away by the CADDR in
CB> RenderSub (plotmath.c l. 1399). Maybe changing this
CB> could be considered as "low-priority desired" (would be
CB> nice if the output works for ?
>>
>> I agree this is a ``missing feature'' and well worth wish
>> list item.
>>
CB> However, I suggest to announce the fact that only the
CB> first parameter is printed in plotmath.Rd.
>>
CB> E.g. in the table l. 72 \code{x[i]} \tab x subscript i;
CB> escape further indices (\code{x ["i, j"]})\cr
>>
>> How would get the equivalent of LaTeX x_{i_1, j_2} ? Not
>> by making it a string (that's not escape, I'd say), but
>> by something like
>>
>> plot(0, axes=FALSE, main=
>> expression(paste(x[i[1]],{}[j[2]])))
>>
>> which works +- but of course is unnecessarily ugly,
>> compared to the desired
>>
>> plot(0, axes=FALSE, main= expression( x[i[1], j[2]]))
>>
PE> I don't know if I've ever disagreed with Martin's advice but,
:-)
PE> unless I'm missing something, Claudia wants something
PE> done about the second index in x[i, j] while Martin is
PE> talking about the case of cascading subscripts in
PE> 'x_sub_i_sub_1' (as shown in his LaTeX expression).
Well, that was a misunderstanding.
I've use "cascaded" subscripts as an example of subscripts that
are themselves expressions, and so using a string,
as Claudia's suggestion (on R-devel!) was, is not enough.
Only afterwards, I saw the related thread on R-help,
which included the proposals you give here
PE> Both situations are nicely handled with the 'list()' and '[]'
PE> constructs in plotmath:
PE> plot(0, axes=FALSE, main= expression( x[ list( i[1], j[2] ) ] ) )
PE> To handle Claudia's wish, it might be desirable to have plotmath.c
PE> automatically recognize such cases but I would consider that to
PE> be (as Claudia says) in the 'nice if' category. Claudia's suggestion
PE> for the help page could be handled by adding another example. Then
PE> again, plotmath (not surprisingly) is like LaTeX in that, the more
PE> you use it, the more you become familiar with the special constructs
PE> needed to get the output you want. I still find myself scurrying to
PE> ?plotmath and scanning the Syntax/Meaning table quite frequently.
okay.
Indeed, the following code snippet shows what I deem a summary
of the proposals seen.
Txt <- function(y, exp) {
y <- y/16 # to allow integer arguments on input
x0 <- par("xaxp")[1]
text(y, exp, adj = 0, cex = 5)
text(y, deparse(substitute(exp)), adj = 1.1, cex=1.2)
}
plot(0, axes=FALSE,ann=FALSE, asp=1, type="n")
## These show no "," between the two indices:
Txt( 0, expression(x[paste(i[1],j[2])]))
Txt( 2, expression(x[i[1]][j[2]])) ## <-- clearly nicest
## This one does .. that's what Claudia wanted:
Txt(-3, expression(x[list(i[1],j[2])]))
## and this one uses extra space
Txt(-5, expression(x[list(~i[1],j[2])]))
g <- seq(-1.6,1, .2)/4; abline(v=g+1, h=g, col=adjustcolor(1, .2))
Notably the distinction between (LaTeX)
x_{i,j} or x_{i_1, j_2}
and
x_{ij} or x_{i_1 i_2}
is something that the useR will want to be able to specify with
plotmath as well.
So Claudia's (and my) wish that x[i,j] (or x[i[1], j[2]] )
also work automatically in R's plotmath
would still have to say if we want the version with "," or
without.
Martin
PE> Peter Ehlers
>> Martin
>>
CB> Claudia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows script editor and locale
Maybe I'm just overlooking something, but I can't figure out how to set/change the locale of a file loaded into the built-in script editor on Windows. The generic issue is that if I make a teaching script on a Mac, save it to a USB stick, and open it in the script editor in a classroom, then special Danish characters in the comments come out as two-byte sequences, which are pretty unsightly. I know that I can convert the file with iconv (or iconv()), but then I'd have to maintain two copies of the same file for the two operating systems, if I want the students to access it. Would be nice if there was something like a set-coding-system to call up via a menu item. Any pointers? -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Windows script editor and locale
There is no support for files in alternative encodings in RGui's menus: not to source files nor to load into a pager or the script editor. (I believe all of those long predate any support for encodings in R.) Such provision is rather rare on Windows: files are almost everywhere assumed to be in the current Windows codepage (or sometimes WinANSI, as in the 'Command prompt' terminal) or in so-called Unicode (usually UCS-2LE, possibly UTF-16LE, with a BOM). I think you could equally ask the same question in reverse: AFAICS the R.app GUI has no support for Latin-1 nor UCS-2LE files. At least in our UK experience, the proportion of non-Windows users is so low that it is those (including this instructor) who expect to adjust. What might make some sense is for file.edit() to gain a 'fileEncoding' argument so this could at least be done from the command-line. On Fri, 21 Jan 2011, peter dalgaard wrote: Maybe I'm just overlooking something, but I can't figure out how to set/change the locale of a file loaded into the built-in script editor on Windows. The generic issue is that if I make a teaching script on a Mac, save it to a USB stick, and open it in the script editor in a classroom, then special Danish characters in the comments come out as two-byte sequences, which are pretty unsightly. I know that I can convert the file with iconv (or iconv()), but then I'd have to maintain two copies of the same file for the two operating systems, if I want the students to access it. Would be nice if there was something like a set-coding-system to call up via a menu item. Any pointers? -- Peter Dalgaard Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] plotmath indices: suggested addition to help file
Dear all,
after realizing yesterday that my suggestion was not yet quite "ripe" as the
character version is very limited, I decided to wait a bit before summarizing
the outcome to a better proposition instead of creating too much fuss.
Martin, thanks for your support & systematic table :-)
My main point is that somehow I didn't at all expect plotmath to throw away
everything after the i of expression (x [i,j]). I think this "trap" deserves
either change (nice to have; I now believe that this may be quite easy, see
below) or at least an announcement.
I agree that one needs to learn dealing with plotmath. On the other hand, it is
nice if plotmath's output corresponds to the R meaning of the expression.
I guess the underlying problem is that we have three different possibilities
with indexing:
R ---> how I'd write down the R meaning
(a) x [i, j] ---> x_{i, j} or x_{i j} (not x_{ij})
(b) x [i [j]] ---> x_i_j
(c) x [i][j] ---> (x_i)_j
(b) works as expected, though a tiny little bit more default space would be
excellent.
(a) produces plotmath output x_i which is _very_ unexpected, and
(c) produces output that looks very similar to my expectation for (a) and can
thus be used to cheat around unexpected behaviour of (a).
I'd say the behaviour of (c) is fine, and it is up to me to write (x [i])[j].
Note that writing (x [i]) [j] does not change the R meaning of the expression.
BTW: I prefer a comma for (a) because i couldn't distinguish the output of
expression (x [i][j])
from
expression (x [ij])
.
I also vote for a comma for the future behaviour of (a) - even with some space
it's easier to distinguish two indices if they are separated by a comma (and no
comma can still be obtained by x[i][j]). Plus, it may be easier to implement it
that way.
I tried:
CDDR instead CADDR in RenderSub (plotmath.c) yields all indices given in the
square bracket. Now I prepended install ("list") by LCONS, and it seems to work:
plot (1,1, type = "n"); text (1, 1, expression (x [i[a,b,c],j,k]*f(x)), cex = 3)
now looks as I expect.
Disclaimer: This is the first time ever I tried to do something with the R C
interface, and I didn't even properly read the maual and SoDa chapters. So I
have no idea whether I did something that will cause trouble.
Best regards & have a nice weekend
Claudia
cb@cb:~/r-devel$ svn diff src/main/plotmath.c
Index: src/main/plotmath.c
===
--- src/main/plotmath.c (revision 54062)
+++ src/main/plotmath.c (working copy)
@@ -898,6 +898,7 @@
mathContext*, pGEcontext , pGEDevDesc);
static BBOX RenderExpression(SEXP, int, mathContext*, pGEcontext , pGEDevDesc);
static BBOX RenderSymbolChar(int, int, mathContext*, pGEcontext , pGEDevDesc);
+static BBOX RenderCommaList(SEXP, int, mathContext *, pGEcontext, pGEDevDesc);
/* Code to Generate Bounding Boxes and Draw Formulae. */
@@ -1396,7 +1397,8 @@
{
BBOX bodyBBox, subBBox;
SEXP body = CADR(expr);
-SEXP sub = CADDR(expr);
+SEXP sub = CDDR(expr);
+SEXP list = install ("list");
STYLE style = GetStyle(mc);
double savedX = mc->CurrentX;
double savedY = mc->CurrentY;
@@ -1407,6 +1409,7 @@
s5 = TeX(sigma5, gc, dd);
s16 = TeX(sigma16, gc, dd);
SetSubStyle(style, mc, gc);
+sub = LCONS (list, sub);
subBBox = RenderElement(sub, 0, mc, gc, dd);
v = max(max(v, s16), bboxHeight(subBBox) - 0.8 * sigma5);
subBBox = RenderOffsetElement(sub, 0, -v, draw, mc, gc, dd);
--
Claudia Beleites
Dipartimento dei Materiali e delle Risorse Naturali
Università degli Studi di Trieste
Via Alfonso Valerio 6/a
I-34127 Trieste
phone: +39 0 40 5 58-37 68
email: cbelei...@units.it
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
