Re: [Rd] (PR#7976) split() dropping levels (was "boxplot by factor")
[ Hmm, is everyone of those interested in changes inside R "sleeping" ,
uninterested, ...
]
> "MM" == Martin Maechler <[EMAIL PROTECTED]>
> on Fri, 1 Jul 2005 18:36:54 +0200 writes:
> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
> on 28 Jun 2005 14:57:42 +0200 writes:
PD> "Liaw, Andy" <[EMAIL PROTECTED]> writes:
>>> The issue is not with boxplot, but with split. boxplot.formula()
>>> calls boxplot(split(split(mf[[response]], mf[-response]), ...),
>>> but look at what split() returns when there are empty levels in
>>> the factor:
>>>
>>> > f <- factor(gl(3, 6), levels=1:5)
>>> > y <- rnorm(f)
>>> > split(y, f)
>>> $"1"
>>> [1] 0.4832124 1.1924811 0.3657797 1.7400198 0.5577356 0.9889520
>>>
>>> $"2"
>>> [1] -1.1296642 -0.4808355 -0.2789933 0.1220718 0.1287742 -0.7573801
>>>
>>> $"3"
>>> [1] 1.2320902 0.5090700 -1.5508074 2.1373780 1.1681297 -0.7151561
>>>
>>> The "culprit" is the following in split.default():
>>>
>>> f <- factor(f)
>>>
>>> which drops empty levels in f, if there are any. BTW, ?split doesn't
>>> mention what it does in such situation. Perhaps it should?
>>>
>>> If this is to be "fixed", I suppose an additional argument, e.g.,
>>> drop=TRUE, can be added, and the corresponding line mentioned
>>> above changed to something like:
>>>
>>> if (drop || !is.factor(f)) f <- factor(f)
>>>
>>> Then this additional argument can be pass on from boxplot.formula() to
>>> split().
PD> Alternatively, I suspect that the intention was as.factor() rather
PD> than factor().
MM> at first I thought Peter was right; but the real source of
MM> split.default contains a comment (!) and that line is
MM> f <- factor(f) # drop extraneous levels
MM> so it seems, this was done there very much on purpose.
MM> OTOH, S(-plus) has implemented it quite a bit differently, and actually
MM> does keep the empty levels in the example
MM> f <- factor(rep(1:3, each=6), levels=1:5); y <- rnorm(f); split(y, f)
PD> It does require a bit of care to fix it that way,
PD> though. There could be problems with empty levels popping up in
PD> unexpected places.
MM> Indeed!
MM> Given the new facts, I think we want to go in Andy's direction
MM> with a new argument, 'drop'
MM> A Peter mentioned, the real question is about its default.
MM> "drop = TRUE" would be fully compatible with previous versions of R.
MM> "drop = FALSE" would be compatible with S and S-plus.
MM> I'm going to implement it, and try to see if 'drop = FALSE'
MM> gives changes for R and its standard packages; if 'yes', that
MM> would be an indication that such a R-back-compatibility breaking
MM> change was not a good idea. If 'no', I could commit it and see
MM> if it has an effect on the CRAN packages
MM> Of course, since split() and split()<- are S3 generics, and
MM> since there's also unsplit(), this entails a whole slew of
MM> changes {adding a "drop = FALSE" argument everywhere!}
MM> and I presume will break everyone's code who has written own
MM> split.foobar methods
MM> great...
MM> Martin
The change doesn't seem to affect the "standard" packages at all
which is good. On CRAN, it seems there are two packages only that
have split() or split()<- methods, namely 'spatstat' and 'compositions'.
If we introduced the extra argument 'drop',
these and every other user code defining split methods would
have to be updated to be compatible with the changed (S3)
generic having an extra argument 'drop'.
With this in mind, after more thought, I think that Peter's
initial proposal ---just replacing 'factor()' by 'as.factor()'
inside split--- seems to be nicer than introducing 'drop' and
*change* the default behavior to 'drop = FALSE' for the
following reasons :
1) people who rely on the current behavior would have to change
their calls to split() anyway;
2) instead of calling
split(x, f, drop=TRUE)
they can as well go for
split(x, factor(f))
which has identical effect but does not introduce an extra
argument 'drop'.
3) advantage of slightly higher compatibility with S
---
I intend to change this in R-devel
{with appropriate notes in NEWS !} during this week, unless
someone finds good reasons for a different (or no) change.
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] eigen of a real pd symmetric matrix gives NaNs in $vector (PR#7987)
Full_Name: cajo ter Braak Version: 2.1.1 OS: Windows Submission from: (NULL) (137.224.10.105) # I would like to attach the matrix C in the Rdata file; it is 50x50 and comes from a geostatistical problem (spherical covariogram) > rm(list=ls(all=TRUE)) > load(file= "test.eigen.Rdata") > ls() [1] "C" "eW" > > sym.check = max(abs(C - t(C)))# should be 0 for symmetry > sym.check [1] 0 > eW <-eigen(C, symmetric = TRUE) > l_eW <- eW$values > print(eW$values) [1] 4.5730646 4.5730646 3.3066738 3.3066738 3.3066738 3.3066738 2.3935268 [8] 2.3935268 1.9367508 1.9367508 1.9347787 1.9347787 1.4276845 1.4276845 [15] 1.4276845 1.4276845 0.9858318 0.9858318 0.9858318 0.9858318 0.9123115 [22] 0.9123115 0.7945283 0.7945283 0.7880493 0.7880493 0.6047920 0.6047920 [29] 0.6047920 0.6047920 0.5689609 0.5689609 0.5681210 0.5681210 0.5440676 [36] 0.5440676 0.5440676 0.5440676 0.5224040 0.5224040 0.5139844 0.5139844 [43] 0.5077485 0.5077485 0.5008249 0.5008249 0.5008249 0.5008249 0.4960220 [50] 0.4960220 > #print(eW$vector) > > > #library(MASS) > #n = nrow(C) > #y = runif(n) > > #lm1 = lm.gls(y~1, W = C) > #summary(lm1) > > eW <-eigen(C, symmetric = TRUE) > l_eW <- eW$values > # the thirdteens eigenvector contrains NaN > print(eW$values) [1] 4.5730646 4.5730646 3.3066738 3.3066738 3.3066738 3.3066738 2.3935268 [8] 2.3935268 1.9367508 1.9367508 1.9347787 1.9347787 1.4276845 1.4276845 [15] 1.4276845 1.4276845 0.9858318 0.9858318 0.9858318 0.9858318 0.9123115 [22] 0.9123115 0.7945283 0.7945283 0.7880493 0.7880493 0.6047920 0.6047920 [29] 0.6047920 0.6047920 0.5689609 0.5689609 0.5681210 0.5681210 0.5440676 [36] 0.5440676 0.5440676 0.5440676 0.5224040 0.5224040 0.5139844 0.5139844 [43] 0.5077485 0.5077485 0.5008249 0.5008249 0.5008249 0.5008249 0.4960220 [50] 0.4960220 > print(eW$vector[,13]) [1] 0 NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN [20] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN [39] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] prototypes for z_sin() and z_cos()
Hi I have been looking at complex.c and want to access z_cos() and z_sin () from C in one of my packages. There doesn't seem to be a corresponding header file: there is no complex.h file. Where are the prototypes of z_sin() and z_cos() for these functions? grepping didn't help me: find ~/downloads/R-2.1.1/ -name "*.h " | xargs egrep "z_cos" returned empty. How do I access z_sin() from my c code? -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Southampton European Way, Southampton SO14 3ZH, UK tel 023-8059-7743 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] eigen of a real pd symmetric matrix gives NaNs in $vector (PR#7987)
I would presume this is another manifestation of what I reported (reproduced below) on 2003-12-01. [EMAIL PROTECTED] wrote: >Full_Name: cajo ter Braak >Version: 2.1.1 >OS: Windows >Submission from: (NULL) (137.224.10.105) > > ># I would like to attach the matrix C in the Rdata file; it is 50x50 and comes >from a geostatistical problem (spherical covariogram) > > > >>rm(list=ls(all=TRUE)) >>load(file= "test.eigen.Rdata") >>ls() >> >> >[1] "C" "eW" > > >>sym.check = max(abs(C - t(C)))# should be 0 for symmetry >>sym.check >> >> >[1] 0 > > >>eW <-eigen(C, symmetric = TRUE) >>l_eW <- eW$values >>print(eW$values) >> >> > [1] 4.5730646 4.5730646 3.3066738 3.3066738 3.3066738 3.3066738 2.3935268 > [8] 2.3935268 1.9367508 1.9367508 1.9347787 1.9347787 1.4276845 1.4276845 >[15] 1.4276845 1.4276845 0.9858318 0.9858318 0.9858318 0.9858318 0.9123115 >[22] 0.9123115 0.7945283 0.7945283 0.7880493 0.7880493 0.6047920 0.6047920 >[29] 0.6047920 0.6047920 0.5689609 0.5689609 0.5681210 0.5681210 0.5440676 >[36] 0.5440676 0.5440676 0.5440676 0.5224040 0.5224040 0.5139844 0.5139844 >[43] 0.5077485 0.5077485 0.5008249 0.5008249 0.5008249 0.5008249 0.4960220 >[50] 0.4960220 > > >>#print(eW$vector) >> >> >>#library(MASS) >>#n = nrow(C) >>#y = runif(n) >> >>#lm1 = lm.gls(y~1, W = C) >>#summary(lm1) >> >>eW <-eigen(C, symmetric = TRUE) >>l_eW <- eW$values >># the thirdteens eigenvector contrains NaN >>print(eW$values) >> >> > [1] 4.5730646 4.5730646 3.3066738 3.3066738 3.3066738 3.3066738 2.3935268 > [8] 2.3935268 1.9367508 1.9367508 1.9347787 1.9347787 1.4276845 1.4276845 >[15] 1.4276845 1.4276845 0.9858318 0.9858318 0.9858318 0.9858318 0.9123115 >[22] 0.9123115 0.7945283 0.7945283 0.7880493 0.7880493 0.6047920 0.6047920 >[29] 0.6047920 0.6047920 0.5689609 0.5689609 0.5681210 0.5681210 0.5440676 >[36] 0.5440676 0.5440676 0.5440676 0.5224040 0.5224040 0.5139844 0.5139844 >[43] 0.5077485 0.5077485 0.5008249 0.5008249 0.5008249 0.5008249 0.4960220 >[50] 0.4960220 > > >>print(eW$vector[,13]) >> >> > [1] 0 NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN >NaN >[20] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN >NaN >[39] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN > > This is undoubtedly a bug, but I doubt that it is really down to R. Synopsis: a certain matrix causes eigen(symmetric=TRUE) to produce NaN's in some of the returned eigenvectors. This happens using SuSe 8.2 Professional and the precompiled R rpm (happens in both 1.8.1 and 1.7.1). I don't see it under Windows. To reproduce the bug: The matrix (75 by 75, about 45K) is in http://www.burns-stat.com/pages/Flotsam/eigenbugmatrix.RData Load that into R. sum(is.na(eigen(eigenbugmatrix, symmetric=TRUE)$vectors)) is non-zero (600 in my experience) when the bug is exhibited and is zero when the bug is not. It is quite sensitive to the numbers. The bug is still there with some scaling of the matrix (from about divide by 2 to multiply by 8). The bug disappears if the matrix is dumped and sourced back in again. The only clue that I can offer is that it is vectors 43:50 (I think) that are NaN's and the matrix is logically of rank 50. That is, it is a covariance matrix on 75 variables using 50 observations. Hopefully, someone has the experience and tenacity to figure out what is going on here. Patrick Burns Burns Statistics [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") >__ >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] eigen of a real pd symmetric matrix gives NaNs in $vector (PR#7989)
I would presume this is another manifestation of what I reported (reproduced below) on 2003-12-01. [EMAIL PROTECTED] wrote: >Full_Name: cajo ter Braak >Version: 2.1.1 >OS: Windows >Submission from: (NULL) (137.224.10.105) > > ># I would like to attach the matrix C in the Rdata file; it is 50x50 and comes >from a geostatistical problem (spherical covariogram) > > > >>rm(list=ls(all=TRUE)) >>load(file= "test.eigen.Rdata") >>ls() >> >> >[1] "C" "eW" > > >>sym.check = max(abs(C - t(C)))# should be 0 for symmetry >>sym.check >> >> >[1] 0 > > >>eW <-eigen(C, symmetric = TRUE) >>l_eW <- eW$values >>print(eW$values) >> >> > [1] 4.5730646 4.5730646 3.3066738 3.3066738 3.3066738 3.3066738 2.3935268 > [8] 2.3935268 1.9367508 1.9367508 1.9347787 1.9347787 1.4276845 1.4276845 >[15] 1.4276845 1.4276845 0.9858318 0.9858318 0.9858318 0.9858318 0.9123115 >[22] 0.9123115 0.7945283 0.7945283 0.7880493 0.7880493 0.6047920 0.6047920 >[29] 0.6047920 0.6047920 0.5689609 0.5689609 0.5681210 0.5681210 0.5440676 >[36] 0.5440676 0.5440676 0.5440676 0.5224040 0.5224040 0.5139844 0.5139844 >[43] 0.5077485 0.5077485 0.5008249 0.5008249 0.5008249 0.5008249 0.4960220 >[50] 0.4960220 > > >>#print(eW$vector) >> >> >>#library(MASS) >>#n = nrow(C) >>#y = runif(n) >> >>#lm1 = lm.gls(y~1, W = C) >>#summary(lm1) >> >>eW <-eigen(C, symmetric = TRUE) >>l_eW <- eW$values >># the thirdteens eigenvector contrains NaN >>print(eW$values) >> >> > [1] 4.5730646 4.5730646 3.3066738 3.3066738 3.3066738 3.3066738 2.3935268 > [8] 2.3935268 1.9367508 1.9367508 1.9347787 1.9347787 1.4276845 1.4276845 >[15] 1.4276845 1.4276845 0.9858318 0.9858318 0.9858318 0.9858318 0.9123115 >[22] 0.9123115 0.7945283 0.7945283 0.7880493 0.7880493 0.6047920 0.6047920 >[29] 0.6047920 0.6047920 0.5689609 0.5689609 0.5681210 0.5681210 0.5440676 >[36] 0.5440676 0.5440676 0.5440676 0.5224040 0.5224040 0.5139844 0.5139844 >[43] 0.5077485 0.5077485 0.5008249 0.5008249 0.5008249 0.5008249 0.4960220 >[50] 0.4960220 > > >>print(eW$vector[,13]) >> >> > [1] 0 NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN >NaN >[20] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN >NaN >[39] NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN NaN > > This is undoubtedly a bug, but I doubt that it is really down to R. Synopsis: a certain matrix causes eigen(symmetric=TRUE) to produce NaN's in some of the returned eigenvectors. This happens using SuSe 8.2 Professional and the precompiled R rpm (happens in both 1.8.1 and 1.7.1). I don't see it under Windows. To reproduce the bug: The matrix (75 by 75, about 45K) is in http://www.burns-stat.com/pages/Flotsam/eigenbugmatrix.RData Load that into R. sum(is.na(eigen(eigenbugmatrix, symmetric=TRUE)$vectors)) is non-zero (600 in my experience) when the bug is exhibited and is zero when the bug is not. It is quite sensitive to the numbers. The bug is still there with some scaling of the matrix (from about divide by 2 to multiply by 8). The bug disappears if the matrix is dumped and sourced back in again. The only clue that I can offer is that it is vectors 43:50 (I think) that are NaN's and the matrix is logically of rank 50. That is, it is a covariance matrix on 75 variables using 50 observations. Hopefully, someone has the experience and tenacity to figure out what is going on here. Patrick Burns Burns Statistics [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") >__ >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] Compiling R scripts
Dear R Developers, A recommendation for future development. It would help if R scripts could be compiled into an executable, or a library. Speed is the main issue (I run a large scale monte carlo in R which is very slow). However, it would also make it easier to link R into other applications, easier at least than the COM infrastructure under Windows. Finally, it would make it much easier to farm R apps: rather than distributing all of R and necessary libraries onto each client, and making sure each client is always up to date as libraries for a specific script change, it might be easier just to distribute a simple executable across all nodes. Regards, Tolga == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.csfb.com/legal_terms/disclaimer_external_email.shtml __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compiling R scripts
Uzuner, Tolga wrote: > Dear R Developers, > It would help if R scripts could be compiled into an executable, or a > library. Are you sure it would help? If you do a big matrix operation in R it runs at the speed of the underlying C code. It wont get much faster. Profile your code, find out where the time is being spent, then optimise _that_. > Speed is the main issue (I run a large scale monte carlo in > R which is very slow). The reason its very slow is not because its 'in R' but because it is a 'large scale monte carlo'. What was a 'large scale' monte-carlo ten years ago runs in no time today. 'large scale' == 'slow' almost by definition. Unless you've done comparisons with the same code written in some other language. > However, it would also make it easier to link > R into other applications, easier at least than the COM > infrastructure under Windows. R can be called from C, and there are application links to Python, Perl, Java... Easy enough. > Finally, it would make it much easier to farm R apps: rather than > distributing all of R and necessary libraries onto each client, and > making sure each client is always up to date as libraries for a > specific script change, it might be easier just to distribute a > simple executable across all nodes. Keeping a bunch of clients up to date is as easy as a quick scripted rsync command, or completely transparent if you have a shared /usr/local filesystem (Unix). There is some work going on to produce an R compiler, but I dont think these are the reasons. Baz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] segmentation fault after max level of parenthesis (PR#7990)
Full_Name: Matthias Laabs Version: 2.1.0 (source compiled) OS: debian linux (sarge) Submission from: (NULL) (195.143.236.2) Hi! R crashes with a segmentation fault when I use more than 85 parenthesis (it actually happened by accidently hitting a wrong shortcut in emacs ... ) code: sum(() cheers from Berlin, Matthias __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How difficult is it to wrap a large C++ library with R?
Dear list, I have developed a forward-time population genetics simulation environment simuPOP, which is a set of C++ (template) classes/functions wrapped by SWIG as Python libraries. R is used extensively as plotting and statistical analysis engine through RPy package. I use Python to wrap simuPOP since most the following can be easily done using SWIG or Python C API. However, since Python is less used by bioinformaticists and geneticists, I am asked again and again why I do not wrap simuPOP with R (R is also OOP etc...). Although I am a long time R user, I am not familiar with package writing in R. From what I read from R website, it is easy to wrap individual C/C++ functions but not C++ classes. Can anyone take the time to review the following and tell me if they can be done (easily or need effort) using R? If most of the answers are yes, it may be a good idea to switch to R. * Wrap C++ class hierarchy. Virtual functions need to be supported. (SWIG can generate Python shadow classes that behave almost exactly like the underlying C++ classes) * Be able to do this: evolve(ops=c(obj1, obj2, obj3)) Internally, evolve will call virtual function fun() of obj1, obj2, .etc. obj1, obj2, ... are objects derived from the same base class. * Direct access to C++ data structure. For example, an object may keep a C array internally. I will need a method (maybe wrap this data into a R object) to read/write this array directly. * create and read/write a R list at C++ level. (Need API for R/list read/write) * pass a user defined R function to C++ function. Call it and obtain result. * evaluate an R expression (passed as string) from within C++ function and obtain result. * pass C++ exceptions to R * be able to use C++ features like template, STL. * organize manual by objects, not functions. (I notice that manuals of R libraries are simple function references.) Many thanks in advance. -- Bo Peng Department of Statistics Rice University http://bp6.stat.rice.edu:8080/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
On 7/4/2005 1:01 PM, Bo Peng wrote: > Dear list, > > I have developed a forward-time population genetics simulation > environment simuPOP, which is a set of C++ (template) > classes/functions wrapped by SWIG as Python libraries. R is used > extensively as plotting and statistical analysis engine through RPy > package. > > I use Python to wrap simuPOP since most the following can be easily > done using SWIG or Python C API. However, since Python is less used by > bioinformaticists and geneticists, I am asked again and again why I do > not wrap simuPOP with R (R is also OOP etc...). Although I am a long > time R user, I am not familiar with package writing in R. From what I > read from R website, it is easy to wrap individual C/C++ functions but > not C++ classes. Can anyone take the time to review the following and > tell me if they can be done (easily or need effort) using R? If most > of the answers are yes, it may be a good idea to switch to R. > > * Wrap C++ class hierarchy. Virtual functions need to be supported. > (SWIG can generate Python shadow classes that behave almost exactly > like the underlying C++ classes) This is hard to do in R, because the R object model is quite different from that of C++ (whereas Python's is more similar). > * Be able to do this: > evolve(ops=c(obj1, obj2, obj3)) > Internally, evolve will call virtual function fun() of obj1, obj2, .etc. > obj1, obj2, ... are objects derived from the same base class. This wouldn't be hard, assuming that the 3 objects have classes, and there's a generic function fun() which owns methods supporting those classes. (In R, objects don't have virtual functions, generic functions do.) > * Direct access to C++ data structure. For example, an object may keep > a C array internally. I will need a method (maybe wrap this data into > a R object) to read/write this array directly. That's not too hard provided you use C++ code to do the actual access. That is, you write an R function that calls C++ code to do the work. It's a lot harder if you want to keep it all in R, because it doesn't understand C++ type definitions, alignment conventions, etc. > * create and read/write a R list at C++ level. (Need API for R/list > read/write) That's not too hard. There are lots of examples in contributed libraries, and it's documented in the R Extensions manual. > > * pass a user defined R function to C++ function. Call it and obtain result. Ditto. > > * evaluate an R expression (passed as string) from within C++ function > and obtain result. Ditto. > > * pass C++ exceptions to R That's hard, because R won't know what to do with them. There are ways to turn C++ exceptions into R errors, but they are not well documented, and I suspect you'll need to do most of the work (i.e. have an exception handler that calls an internal R function). > * be able to use C++ features like template, STL. In your own C++ code? If gcc supports them, it'll be easy. If you need a special compiler, it'll be harder. In R code? Forget it. > * organize manual by objects, not functions. (I notice that manuals of > R libraries are simple function references.) You can write a vignette organized any way you like. The code that shows up in the printed manuals is just a collection of Rd man pages, organized more or less alphabetically. > Many thanks in advance. > > -- > Bo Peng > Department of Statistics > Rice University > http://bp6.stat.rice.edu:8080/ > > __ > 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] [R] How to convert "c:\a\b" to "c:/a/b"
ANOTHER EXAMPLE FOR "gsub"?
I would like to suggest that some version of Prof. Ripley's answer to
my recent post to r-help (subject as above) be added to the "Examples"
for "gsub":
## CAUTION: XEmacs may hang on "readLines"
## unless submitted by itself
(x <- readLines(stdin(), n=1))
D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
(x <- gsub("", "/", x))
ANOTHER OPTION FOR "readLines"?
I don't know if this issue is sufficiently important to justify
adding an argument to have "readLines" to change "\" to "/", but if so,
it does not seem difficult:
readLines. <-
function (con = stdin(), n = -1, ok = TRUE,
reverseBackSlash=FALSE)
{
if (is.character(con)) {
con <- file(con, "r")
on.exit(close(con))
}
if(reverseBackSlash){
dat <- .Internal(readLines(con, n, ok))
return(gsub("", "/", dat))
}
.Internal(readLines(con, n, ok))
}
(x <- readLines.(stdin(), n=1, reverseBackSlash=TRUE))
D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
This has been tested (in this one example) under XEmacs / ESS and
Rgui for R 2.1.1 patched.
Thanks for your great support of the R project and through that
making it much easier for people to learn and use improved statistical
methods and to advance the science even further.
Best Wishes,
spencer graves
Spencer Graves wrote:
> Thank You, Prof. Ripley!
>
> Both "test1.R" and "test2.R" worked for me just now, as did the
> following minor modification:
>
> (x <- readLines(stdin(), n=1))
> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
>
> Thanks again.
>
> spencer graves
>
> Prof Brian Ripley wrote:
>
>> On Wed, 29 Jun 2005, David Duffy wrote:
>>
>>
>>> I couldn't resist adding a more literal answer
>>
>>
>>
>> This can only work for escapes which are preserved. The parser maps
>> \n to a character (LF) and the deparser maps it back to \n.
>> This happens to be true of \a \b \f \n \r \t \v \\ but no others.
>>
>> For example, \s is mapped to s, and there is no difference between \s and
>> s in the parsed input.
>>
>>
>>> unback <- function(x) {
>>> chars <- unlist(strsplit(deparse(x),""))
>>> chars <- chars[-c(1,length(chars))]
>>> paste(gsub("","/",chars),collapse="")
>>> }
>>>
>>> unback("\n")
>>
>>
>>
>>> unback("\s")
>>
>>
>> [1] "s"
>>
>> Spencer Graves keeps on insisting there is a better way, but all the
>> solutions are to avoid sending the string to the parser, and hence
>> avoiding having the string directly in an R script. This is common in
>> shell scripts, which use 'here' documents to avoid 'quoting hell'.
>>
>> We can do that in R too. Here are two variants I have not seen in the
>> thread
>>
>> test1.R:
>> scan("", "", allowEscapes=FALSE, n=1, quiet=TRUE)
>> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
>> catIx, "\n", sep="")
>>
>> R --slave --vanilla < test1.R
>> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
>>
>> (This one does not allow quoted strings.)
>>
>> test2.R:
>> x <- readLines(stdin(), n=1)
>> "D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt"
>> x <- gsub('^"(.*)"$', "\\1", x)
>> cat(x, "\n")
>>
>> R --slave --vanilla < test2.R
>> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
>>
>> (This one allows surrounding quotes or not.)
>>
>
--
Spencer Graves, PhD
Senior Development Engineer
PDF Solutions, Inc.
333 West San Carlos Street Suite 700
San Jose, CA 95110, USA
[EMAIL PROTECTED]
www.pdf.com
Tel: 408-938-4420
Fax: 408-280-7915
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] How to convert "c:\a\b" to "c:/a/b"
The readLines example, as written, does not work in sourced files and therefore
will not work in the Examples section of .Rd pages either.
Currently readLines does not process its input and I think it would
not be a good idea to change that philosophy.
On 7/4/05, Spencer Graves <[EMAIL PROTECTED]> wrote:
> ANOTHER EXAMPLE FOR "gsub"?
>
> I would like to suggest that some version of Prof. Ripley's answer to
> my recent post to r-help (subject as above) be added to the "Examples"
> for "gsub":
>
> ## CAUTION: XEmacs may hang on "readLines"
> ## unless submitted by itself
> (x <- readLines(stdin(), n=1))
> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
> (x <- gsub("", "/", x))
>
> ANOTHER OPTION FOR "readLines"?
>
> I don't know if this issue is sufficiently important to justify
> adding an argument to have "readLines" to change "\" to "/", but if so,
> it does not seem difficult:
>
> readLines. <-
> function (con = stdin(), n = -1, ok = TRUE,
> reverseBackSlash=FALSE)
> {
> if (is.character(con)) {
> con <- file(con, "r")
> on.exit(close(con))
> }
> if(reverseBackSlash){
> dat <- .Internal(readLines(con, n, ok))
> return(gsub("", "/", dat))
> }
> .Internal(readLines(con, n, ok))
> }
>
> (x <- readLines.(stdin(), n=1, reverseBackSlash=TRUE))
> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
>
> This has been tested (in this one example) under XEmacs / ESS and
> Rgui for R 2.1.1 patched.
>
> Thanks for your great support of the R project and through that
> making it much easier for people to learn and use improved statistical
> methods and to advance the science even further.
>
> Best Wishes,
> spencer graves
>
> Spencer Graves wrote:
>
> > Thank You, Prof. Ripley!
> >
> > Both "test1.R" and "test2.R" worked for me just now, as did the
> > following minor modification:
> >
> > (x <- readLines(stdin(), n=1))
> > D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
> >
> > Thanks again.
> >
> > spencer graves
> >
> > Prof Brian Ripley wrote:
> >
> >> On Wed, 29 Jun 2005, David Duffy wrote:
> >>
> >>
> >>> I couldn't resist adding a more literal answer
> >>
> >>
> >>
> >> This can only work for escapes which are preserved. The parser maps
> >> \n to a character (LF) and the deparser maps it back to \n.
> >> This happens to be true of \a \b \f \n \r \t \v \\ but no others.
> >>
> >> For example, \s is mapped to s, and there is no difference between \s and
> >> s in the parsed input.
> >>
> >>
> >>> unback <- function(x) {
> >>> chars <- unlist(strsplit(deparse(x),""))
> >>> chars <- chars[-c(1,length(chars))]
> >>> paste(gsub("","/",chars),collapse="")
> >>> }
> >>>
> >>> unback("\n")
> >>
> >>
> >>
> >>> unback("\s")
> >>
> >>
> >> [1] "s"
> >>
> >> Spencer Graves keeps on insisting there is a better way, but all the
> >> solutions are to avoid sending the string to the parser, and hence
> >> avoiding having the string directly in an R script. This is common in
> >> shell scripts, which use 'here' documents to avoid 'quoting hell'.
> >>
> >> We can do that in R too. Here are two variants I have not seen in the
> >> thread
> >>
> >> test1.R:
> >> scan("", "", allowEscapes=FALSE, n=1, quiet=TRUE)
> >> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
> >> catIx, "\n", sep="")
> >>
> >> R --slave --vanilla < test1.R
> >> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
> >>
> >> (This one does not allow quoted strings.)
> >>
> >> test2.R:
> >> x <- readLines(stdin(), n=1)
> >> "D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt"
> >> x <- gsub('^"(.*)"$', "\\1", x)
> >> cat(x, "\n")
> >>
> >> R --slave --vanilla < test2.R
> >> D:\spencerg\dataPOWER\stats\Tukey\Boxplot_missing_Tukey2.txt
> >>
> >> (This one allows surrounding quotes or not.)
> >>
> >
>
> --
> Spencer Graves, PhD
> Senior Development Engineer
> PDF Solutions, Inc.
> 333 West San Carlos Street Suite 700
> San Jose, CA 95110, USA
>
> [EMAIL PROTECTED]
> www.pdf.com
> Tel: 408-938-4420
> Fax: 408-280-7915
>
> __
> 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] installing packages and libraries
When I run the following: cd \Rpkgs rcmd install mypackage -l library I get a message that it cannot find quadprog which is a library that mypackage depends on. Error: package 'quadprog' could not be loaded I previously used C:\Program Files\R\rw2011\library as my library for CRAN packages and did not have a problem but now that I use C:\Program Files\R\library this problem has started. I actually can get it to work by doing either of the following: 1. install quadprog into \Program Files\R\rw2011path\library instead of in \Program Files\R\library, or 2. install mypackage into \Program Files\R\library via: rcmd install mypackage -l c:\PROGRA~1\R\library However, I can't seem to install mypackage into \Rpkgs\library like I want due to the error I showed above. I have \Program Files\R\rw2011pat\etc\Renviron.site set to my library list (its contents are just the single line shown here): R_LIBS=C:/PROGRA~1/R/library;C:/Rpkgs/library and normally that works fine, e.g. when doing install.packages to install a CRAN package, but I assume that it is not being read by the installation program. I also tried setting R_LIBS, viz. C:\Rpkgs>set R_LIBS R_LIBS="C:\Program Files\R\library;C:\Rpkgs\library;C:\Program Files\R\rw2011pat \library" but that does not help. In fact, if I do that I get this message: list.files: 'C:/Program Files/R/rw2011pat/library"' is not a readable directory even though that directory is valid as I double checked it. I have looked at ?Startup and the Admin Manual and the Writing Extensions Manual and maybe the answer is there but I have not found it. Anyone know how to get mypackage to install into \Rpkgs\library ? Thanks. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segmentation fault after max level of parenthesis (PR#7990)
Already fixed, I believe. -thomas On Mon, 4 Jul 2005 [EMAIL PROTECTED] wrote: > Full_Name: Matthias Laabs > Version: 2.1.0 (source compiled) > OS: debian linux (sarge) > Submission from: (NULL) (195.143.236.2) > > > Hi! > R crashes with a segmentation fault when I use more than 85 parenthesis (it > actually happened by accidently hitting a wrong shortcut in emacs ... ) > > code: > sum(() > > > cheers from Berlin, > > Matthias > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Thomas Lumley Assoc. Professor, Biostatistics [EMAIL PROTECTED] University of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
> > * Wrap C++ class hierarchy. Virtual functions need to be supported. > > (SWIG can generate Python shadow classes that behave almost exactly > > like the underlying C++ classes) > > This is hard to do in R, because the R object model is quite different > from that of C++ (whereas Python's is more similar). I guess I will have to learn R OOP in detail first. It would be terrible if I will have to re-write every C++ class in R (and without inheritance)! > > * Direct access to C++ data structure. For example, an object may keep > > a C array internally. I will need a method (maybe wrap this data into > > a R object) to read/write this array directly. > > That's not too hard provided you use C++ code to do the actual access. > That is, you write an R function that calls C++ code to do the work. > It's a lot harder if you want to keep it all in R, because it doesn't > understand C++ type definitions, alignment conventions, etc. So this has to be done through functions. In Python, I can create an object to wrap C array that can be accessed just like regular list. I guess it would be difficult to create a new data type in R. Anyway, where can I find the most complete information about implementation of R/OOP at C/C++ level? (Or should I write classes in R and call C++ functions for every member function?) I have not read http://cran.r-project.org/doc/manuals/R-exts.pdf in detail but my impression is that almost everything is done at a function (not object) level using .C(). Thanks. Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
On 7/4/05, Bo Peng <[EMAIL PROTECTED]> wrote: > > > * Wrap C++ class hierarchy. Virtual functions need to be supported. > > > (SWIG can generate Python shadow classes that behave almost exactly > > > like the underlying C++ classes) > > > > This is hard to do in R, because the R object model is quite different > > from that of C++ (whereas Python's is more similar). > > I guess I will have to learn R OOP in detail first. It would be > terrible if I will have to re-write every C++ class in R (and without > inheritance)! What makes you think that there is no inheritance of classes in R? > > > * Direct access to C++ data structure. For example, an object may keep > > > a C array internally. I will need a method (maybe wrap this data into > > > a R object) to read/write this array directly. > > > > That's not too hard provided you use C++ code to do the actual access. > > That is, you write an R function that calls C++ code to do the work. > > It's a lot harder if you want to keep it all in R, because it doesn't > > understand C++ type definitions, alignment conventions, etc. > > So this has to be done through functions. In Python, I can create an > object to wrap C array that can be accessed just like regular list. I > guess it would be difficult to create a new data type in R. > > Anyway, where can I find the most complete information about > implementation of R/OOP at C/C++ level? (Or should I write classes in > R and call C++ functions for every member function?) I have not read > http://cran.r-project.org/doc/manuals/R-exts.pdf in detail but my > impression is that almost everything is done at a function (not > object) level using .C(). Well the R object model is based on generic functions and methods are functions. The S4 class structure differs from the S3 structure in that there is a formal definition of an S4 class but not for an S3 class. However, even in S4, methods do not belong to a class. Methods are intermediate to classes and generic functions and are associated with a signature for the arguments of the generic function. If you want to be able to use S4 classes effectively you should use the .Call interface to compiled code and not the .C interface. If you pass a classed object through the .Call interface to compiled code you can extract or set the values of slots in the object through the GET_SLOT and SET_SLOT macros. Admittedly this is not as convenient for the C++ programmer as being able to pass a pointer to an object from a C++ class but it does make it easier to think of objects in R and the corresponding objects in compiled code. The Matrix package on CRAN contains many examples of this use of this technique. Another technique that you may want to consider is the use of ExternalPointers. If you examine the C source file lmer.c from the aforementioned Matrix package you will see where I create a pointer to a C struct in the compiled code and pass it back to R so it can later be passed to the C code and I can extract the struct. The same could be done for an instance of a C++ class. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
On 7/4/05, Bo Peng <[EMAIL PROTECTED]> wrote:
> > > * Wrap C++ class hierarchy. Virtual functions need to be supported.
> > > (SWIG can generate Python shadow classes that behave almost exactly
> > > like the underlying C++ classes)
> >
> > This is hard to do in R, because the R object model is quite different
> > from that of C++ (whereas Python's is more similar).
>
> I guess I will have to learn R OOP in detail first. It would be
> terrible if I will have to re-write every C++ class in R (and without
> inheritance)!
>
> > > * Direct access to C++ data structure. For example, an object may keep
> > > a C array internally. I will need a method (maybe wrap this data into
> > > a R object) to read/write this array directly.
> >
> > That's not too hard provided you use C++ code to do the actual access.
> > That is, you write an R function that calls C++ code to do the work.
> > It's a lot harder if you want to keep it all in R, because it doesn't
> > understand C++ type definitions, alignment conventions, etc.
>
> So this has to be done through functions. In Python, I can create an
> object to wrap C array that can be accessed just like regular list. I
> guess it would be difficult to create a new data type in R.
>
> Anyway, where can I find the most complete information about
> implementation of R/OOP at C/C++ level? (Or should I write classes in
> R and call C++ functions for every member function?) I have not read
> http://cran.r-project.org/doc/manuals/R-exts.pdf in detail but my
> impression is that almost everything is done at a function (not
> object) level using .C().
>
There are two OO models that come out-of-the-box with R namely S3 and S4.
They are inspired by the Dylan OO model. Others have already mentioned
these. There are also two additional models on CRAN in the R.oo and
proto packages which implement a more conventional class mode (R.oo)
and the prototype model (proto). R.oo has a web site (try google) and
proto has a vignette, i.e. a paper accessible via library(proto);
vignette("proto").
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
On Jul 4, 2005, at 1:01 PM, Bo Peng wrote: > From what I read from R website, it is easy to wrap individual C/C+ > + functions but not C++ classes. There was a couple of posts about this recently: https://stat.ethz.ch/pipermail/r-devel/2005-April/subject.html Look for the posts concerning C++, overloading methods and objects in R. If I remember correctly "Ali" had some prototype automatic wrapper for large classes (he wasn't happy about the performance, but that's another story ;) - see his 'speeding up the library' posts). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] installing packages and libraries
I figured it out. There were quotes around the semicolon separated path. When I removed them it worked. On 7/4/05, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > When I run the following: > > cd \Rpkgs > rcmd install mypackage -l library > > I get a message that it cannot find quadprog which is a library > that mypackage depends on. > > Error: package 'quadprog' could not be loaded > > I previously used C:\Program Files\R\rw2011\library as my library for CRAN > packages and did not have a problem but now that I use > C:\Program Files\R\library this problem has started. > > I actually can get it to work by doing either of the following: > > 1. install quadprog into \Program Files\R\rw2011path\library > instead of in \Program Files\R\library, or > > 2. install mypackage into \Program Files\R\library via: > > rcmd install mypackage -l c:\PROGRA~1\R\library > > However, I can't seem to install mypackage into \Rpkgs\library > like I want due to the error I showed above. > > I have \Program Files\R\rw2011pat\etc\Renviron.site set to my > library list (its contents are just the single line shown here): > > R_LIBS=C:/PROGRA~1/R/library;C:/Rpkgs/library > > and normally that works fine, e.g. when doing install.packages > to install a CRAN package, but I assume that it is not being > read by the installation program. I also tried setting R_LIBS, viz. > > C:\Rpkgs>set R_LIBS > R_LIBS="C:\Program Files\R\library;C:\Rpkgs\library;C:\Program > Files\R\rw2011pat > \library" > > but that does not help. In fact, if I do that I get this message: > > list.files: 'C:/Program Files/R/rw2011pat/library"' is not a readable > directory > > even though that directory is valid as I double checked it. > > I have looked at ?Startup and the Admin Manual and the Writing Extensions > Manual and maybe the answer is there but I have not found it. > > Anyone know how to get mypackage to install into \Rpkgs\library ? > > Thanks. > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
> SWIG is a very nice idea. ... SWIG is a wonderful tool that makes wrapping C++ code super-easy. I can write pure C++ code and even test them by writing a main() function. Then, using a simple interface file, all my C++ classes becomes Python (shadow) classes like magic. It will take much more time to develop simuPOP if I had to modify interface files manually for every change to the C++ classes. > I hope to have a prototype of a general mechanism for generating > bindings to other code for R sometime over the summer. > It has been hatching for some time and it is primarily a matter of > getting the time to implement the existing ideas. Since you already know how to wrap C++ classes to R classes, maybe it is a good idea to ask SWIG developers how to use SWIG to bridge them. After all, SWIG has a mature set of tools to parse C++ code and generate interfaces to more than a dozen scripting languages. Personally, if I have to write interfaces manually for my 40+ classes and a lot more functions, I would rather devote time in adding R support for SWIG. Thanks. Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How difficult is it to wrap a large C++ library with R?
> There was a couple of posts about this recently: > > https://stat.ethz.ch/pipermail/r-devel/2005-April/subject.html > I am too new to this list to see these discussions. They are quite interesting! Certainly I was not aware of the big differences between C++/Python OOP and S3/S4 OOP. This explains why I skipped the OOP part of the red S-Plus manual when I was learning S-Plus: I was not able to get the ideas although I was an experienced C++ programmer. Regardless of the question of 'which OOP is better', I certainly agree with Nathan's opinion that R has lost many users/developers who only know C++/Python OOP. I think I would better continue to use Python to wrap my C++ code (until Ali find a good way to automatically wrap C++ code, or SWIG adds R support). It is simply much easier and more efficient. Destructing my C++ classes into C pieces and reconstruct them in S4 way would be tedious, and the performance penalty will most possibly be disastrous for this simulation environment. Cheers, Bo __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
