[Rd] Strange behavior of assign in a S4 method.
Hi the list,
I define a method that want to change an object without assignation
(foo(x) and not x<-foo(x)) using deparse and assign.
But when the argument of the method does not match *exactly* with the
definition of the generic function, assign does not work...
Anything wrong?
Christophe
#-- Does not work --#
setGeneric("foo1",function(x,...){standardGeneric("foo1")})
setMethod(f="foo1",signature="numeric",definition=
function(x,y=1,...){
nameX<-deparse(substitute(x))
x <- x^2
assign(nameX,x,envir=parent.frame())
}
)
e <- 3
foo1(e,y=5)
cat(e)
#-- Does work --#
setGeneric("foo2",function(x,...){standardGeneric("foo2")})
setMethod(f="foo2",signature="numeric",definition=
function(x,...){
nameX<-deparse(substitute(x))
x <- x^2
assign(nameX,x,envir=parent.frame())
}
)
e <- 3
foo2(e,y=5)
cat(e)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tcltk and R
I have had some comments on sqldf regarding its dependence on tcltk such as the second last sentence on this blog post: http://translate.google.com/translate?hl=en&sl=zh-CN&u=http://www.wentrue.net/blog/%3Fp%3D453&prev=http://blogsearch.google.com/blogsearch%3Fhl%3Den%26ie%3DUTF-8%26q%3Dsqldf%26lr%3D%26sa%3DN%26start%3D10 sqldf does not directly use tcltk but it does use strapply in gsubfn for its parsing and strapply uses tcl from the tcltk package to it speed up -- there is also an all R version of strapply but the gsubfn package as a whole still depends on tcltk whether or not the user uses tcltk or not.I was thinking of changing the Depends:tcltk of gsubfn to Suggests:tcltk and then checking for tcltk availability at run time so if not available it would use the slower all R version; however, I was under the impression that all R platforms have a distribution of R that includes tcltk so in principle this should not be necessary. Is that right regarding tcltk availability on various platforms? What is the situation here? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk and R
R can be built without tcl/tk and so I think it would still be good to check at runtime. -roger On Mon, Mar 15, 2010 at 11:21 AM, Gabor Grothendieck wrote: > I have had some comments on sqldf regarding its dependence on tcltk > such as the second last sentence on this blog post: > > http://translate.google.com/translate?hl=en&sl=zh-CN&u=http://www.wentrue.net/blog/%3Fp%3D453&prev=http://blogsearch.google.com/blogsearch%3Fhl%3Den%26ie%3DUTF-8%26q%3Dsqldf%26lr%3D%26sa%3DN%26start%3D10 > > sqldf does not directly use tcltk but it does use strapply in gsubfn > for its parsing and strapply uses tcl from the tcltk package to it > speed up -- there is also an all R version of strapply but the gsubfn > package as a whole still depends on tcltk whether or not the user uses > tcltk or not. I was thinking of changing the Depends:tcltk of > gsubfn to Suggests:tcltk and then checking for tcltk availability at > run time so if not available it would use the slower all R version; > however, I was under the impression that all R platforms have a > distribution of R that includes tcltk so in principle this should not > be necessary. > > Is that right regarding tcltk availability on various platforms? What > is the situation here? > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Associative array?
If I recall correctly, I thought indexing a vector/list with a character vector uses hashing if the vector is over a certain length (I can't remember the cutoff). Otherwise, it's a linear operation. -roger On Thu, Mar 11, 2010 at 8:09 PM, Ben wrote: >> lists are generic vectors with names so lookup is O(n). Environments >> in R are true hash tables for that purpose: > > Ahh, thanks for the information! A function I wrote before indexing > on a data frame was slower than I expected, and now I know why. > >> I don't quite understand - characters are (after raw vectors) the >> most expressive data type, so I'm not quite sure why that would be a >> limitation .. You can cast anything (but raw vector with nulls) into >> to a character. > > It's no big problem, it's just that if the solution is to convert to > character type, then there are some implementation details to worry > about. For instance, I assume that as.character(x) is a reversible > 1-1 mapping if x is an integer (and not NA or NULL, etc). But > apparently that isn't exactly true for floats, and it would get more > complicated for other data types. So that's why I said it would not > be elegant, but that is a very subjective statement. > > On a deeper level, it seems counterintuitive to me that indexing in R > is O(n). Futhermore, associative arrays are a fundamental data type, > so I think it's weird that I can read the R tutorial, the R language > definition, and even the manual page for new.env() and still not have > enough information to build a decent one. So IMHO things would be > better if R had a built-in easy-to-use general purpose associative > array. > >> I don't see a problem thus I'm not surprised it didn't come up >> ;). But maybe I'm just missing your point ... > > Nope, this has come up before---I think R and I are just on different > wavelengths. Various things that I think are a problem with R are > apparently not, and it's fine the way it is. > > Anyway, sorry for getting off topic ;-) You posted everything I need to know > and I really appreciate your help. > > > -- > Ben Escoto > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Associative array?
Roger, On Mar 15, 2010, at 15:25 , Roger Peng wrote: If I recall correctly, I thought indexing a vector/list with a character vector uses hashing if the vector is over a certain length (I can't remember the cutoff). Otherwise, it's a linear operation. What I was talking about was lookup of one element in a named generic vector of length n so that is linear (~O(n)), because we were discussing l[[i]]. But, yes, you're right that if you use a vector for indexing x[y] (a slightly different topic but applicable to the data table example) then match() is used (=hashing) if either the subscript or names are long enough (subscrip...@493 has the exact formula). Cheers, Simon On Thu, Mar 11, 2010 at 8:09 PM, Ben wrote: lists are generic vectors with names so lookup is O(n). Environments in R are true hash tables for that purpose: Ahh, thanks for the information! A function I wrote before indexing on a data frame was slower than I expected, and now I know why. I don't quite understand - characters are (after raw vectors) the most expressive data type, so I'm not quite sure why that would be a limitation .. You can cast anything (but raw vector with nulls) into to a character. It's no big problem, it's just that if the solution is to convert to character type, then there are some implementation details to worry about. For instance, I assume that as.character(x) is a reversible 1-1 mapping if x is an integer (and not NA or NULL, etc). But apparently that isn't exactly true for floats, and it would get more complicated for other data types. So that's why I said it would not be elegant, but that is a very subjective statement. On a deeper level, it seems counterintuitive to me that indexing in R is O(n). Futhermore, associative arrays are a fundamental data type, so I think it's weird that I can read the R tutorial, the R language definition, and even the manual page for new.env() and still not have enough information to build a decent one. So IMHO things would be better if R had a built-in easy-to-use general purpose associative array. I don't see a problem thus I'm not surprised it didn't come up ;). But maybe I'm just missing your point ... Nope, this has come up before---I think R and I are just on different wavelengths. Various things that I think are a problem with R are apparently not, and it's fine the way it is. Anyway, sorry for getting off topic ;-) You posted everything I need to know and I really appreciate your help. -- Ben Escoto __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Strange behavior of assign in a S4 method.
Dear Christophe
type
showMethods("foo1", inc=TRUE)
showMethods("foo2", inc=TRUE)
to see the difference between the two functions, and this will explain
their different behaviour. This feature of S4 has been discussed here
many times before, see e.g.:
http://tolstoy.newcastle.edu.au/R/e4/help/08/01/1676.html
Perhaps juggling with the 'n' argument of 'parent.frame' could help in
hacking something together that 'works', but as far as I can see what
you want to is an abuse of R's pass by value / functional language
semantics.
For example, try these and check whether this results in what you intended:
foo2(3)
foo2(e+2)
sapply(1:5, foo2)
ls()
Best wishes
Wolfgang
Christophe Genolini scripsit 15/03/10 11:33:
Hi the list,
I define a method that want to change an object without assignation
(foo(x) and not x<-foo(x)) using deparse and assign.
But when the argument of the method does not match *exactly* with the
definition of the generic function, assign does not work...
Anything wrong?
Christophe
#-- Does not work --#
setGeneric("foo1",function(x,...){standardGeneric("foo1")})
setMethod(f="foo1",signature="numeric",definition=
function(x,y=1,...){
nameX<-deparse(substitute(x))
x <- x^2
assign(nameX,x,envir=parent.frame())
}
)
e <- 3
foo1(e,y=5)
cat(e)
#-- Does work --#
setGeneric("foo2",function(x,...){standardGeneric("foo2")})
setMethod(f="foo2",signature="numeric",definition=
function(x,...){
nameX<-deparse(substitute(x))
x <- x^2
assign(nameX,x,envir=parent.frame())
}
)
e <- 3
foo2(e,y=5)
cat(e)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Wolfgang Huber
EMBL
http://www.embl.de/research/units/genome_biology/huber/contact
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tcltk and R
Gabor Grothendieck wrote: > I have had some comments on sqldf regarding its dependence on tcltk > such as the second last sentence on this blog post: > > http://translate.google.com/translate?hl=en&sl=zh-CN&u=http://www.wentrue.net/blog/%3Fp%3D453&prev=http://blogsearch.google.com/blogsearch%3Fhl%3Den%26ie%3DUTF-8%26q%3Dsqldf%26lr%3D%26sa%3DN%26start%3D10 > > sqldf does not directly use tcltk but it does use strapply in gsubfn > for its parsing and strapply uses tcl from the tcltk package to it > speed up -- there is also an all R version of strapply but the gsubfn > package as a whole still depends on tcltk whether or not the user uses > tcltk or not.I was thinking of changing the Depends:tcltk of > gsubfn to Suggests:tcltk and then checking for tcltk availability at > run time so if not available it would use the slower all R version; > however, I was under the impression that all R platforms have a > distribution of R that includes tcltk so in principle this should not > be necessary. > > Is that right regarding tcltk availability on various platforms? What > is the situation here? Hmm, judging by the Mac situation, I wouldn't count on it. We have tcltk working on all the major platforms, but we do allow for compilation without it (e.g. for compute servers), and at least in the Mac case, we need to use a suboptimal version because of the event loop battle. If Apple didn't support X11 (well, sort of), we'd be without Tk there. (We do, byt the way, handle the case where the display is absent, but there really ought to be a neater way to load Tcl without Tk.) -- Peter Dalgaard Center for Statistics, Copenhagen Business School 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
[Rd] Making descriptive analyisis in R
when I try to make a package coping R code such as tab1, summ, titleString, setTitle from epicalc package, the following problems are found. * using log directory 'C:/Rpackage/EpiStat.Rcheck' * using R version 2.10.0 (2009-10-26) * using session charset: ISO8859-1 * checking for file 'EpiStat/DESCRIPTION' ... OK * checking extension type ... Package * this is package 'EpiStatNutshell' version '1.0' * checking package dependencies ... OK * checking if this is a source package ... OK * checking for executable files ... OK * checking whether package 'EpiStatNutshell' can be installed ... OK * checking package directory ... OK * checking for portable file names ... OK * checking DESCRIPTION meta-information ... OK * checking top-level files ... OK * checking index information ... OK * checking package subdirectories ... OK * checking R files for non-ASCII characters ... OK * checking R files for syntax errors ... OK * checking whether the package can be loaded ... OK * checking whether the package can be loaded with stated dependencies ... OK * checking for unstated dependencies in R code ... OK * checking S3 generic/method consistency ... OK * checking replacement functions ... OK * checking foreign function calls ... OK * checking R code for possible problems ... NOTE setTitle: no visible binding for '<<-' assignment to '.locale' summ: no visible binding for global variable '.data' summ: no visible global function definition for 'date.mdy' summ: no visible binding for global variable '.ylab.for.summ' summ: no visible binding for global variable '.No.of.observations' summ: no visible binding for global variable '.obs' summ: no visible binding for global variable '.mean' summ: no visible binding for global variable '.median' summ: no visible binding for global variable '.sd' summ: no visible binding for global variable '.min' summ: no visible binding for global variable '.max' summ: no visible binding for global variable '.var.name' tab1: no visible binding for global variable '.frequency' tab1: no visible binding for global variable '.frequency1' tab1: no visible binding for global variable '.percent' tab1: no visible binding for global variable '.cum.percent' tableGlm: no visible global function definition for 'glm.nb' tableStack: no visible binding for global variable '.data' titleString: no visible binding for global variable '.distribution.of' titleString: no visible binding for global variable '.by' titleString: no visible binding for global variable '.frequency' titleString: no visible binding for global variable '.locale' titleString: no visible binding for '<<-' assignment to '.locale' titleString: no visible binding for '<<-' assignment to '.distribution.of' titleString: no visible binding for '<<-' assignment to '.by' titleString: no visible binding for '<<-' assignment to '.frequency' * checking Rd files ... OK * checking Rd metadata ... OK * checking Rd cross-references ... OK * checking for missing documentation entries ... OK * checking for code/documentation mismatches ... OK * checking Rd \usage sections ... OK * checking examples ... OK when I run this package in R console, > summ(age) Error in titleString() : object '.locale' not found > tab1(porp) Error in titleString() : object '.locale' not found I found this error. How can I solve this problem? I would like to make a package only for descripitve study. Thank a lot -- This message was sent on behalf of kyawkkh...@gmail.com at openSubscriber.com http://www.opensubscriber.com/messages/r-devel@r-project.org/topic.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segfault Problem c++ R interface (detailed)
Hi, First thing to observe is that you are calling RSymbReg via .Call, but that function does not return SEXP as is required by the .Call interface. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Segfault Problem c++ R interface (detailed)
Thank you so much! Although the memory leak is still there after the fix you suggested, gdb is giving me better outputs and I believe I can trace the memory leak origin. -Hyunseung On Mon, Mar 15, 2010 at 2:53 PM, Seth Falcon wrote: > Hi, > > First thing to observe is that you are calling RSymbReg via .Call, but that > function does not return SEXP as is required by the .Call interface. > > + seth > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list_files() memory corruption?
Hi Alistair, On 3/12/10 4:37 PM, Alistair Gee wrote: > I am using R-2-10 from subversion. > > In the implementation of do_listfiles() in platform.c, it appears to > allocate a vector of length count where count is calculated by > count_files(). It then proceeds to call list_files(), passing in the > vector but not the value of count. Yet list_files() doesn't seem to > check the length of the vector that was allocated. > > What happens if a new file was added to the file system between the > call to count_files() and list_files()? Doesn't this write past the > length of the allocated vector? Good catch. I've added a length check to prevent a problem. Cheers, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list_files() memory corruption?
I think I have a fix that avoids the problem by just growing the vector as necessary as the directory is traversed (and no longer uses count_lines()). I don't have access to the code at the moment, but I should be able to post the patch tomorrow. Is there interest in my patch? On Mon, Mar 15, 2010 at 8:06 PM, Seth Falcon wrote: > Hi Alistair, > > On 3/12/10 4:37 PM, Alistair Gee wrote: >> I am using R-2-10 from subversion. >> >> In the implementation of do_listfiles() in platform.c, it appears to >> allocate a vector of length count where count is calculated by >> count_files(). It then proceeds to call list_files(), passing in the >> vector but not the value of count. Yet list_files() doesn't seem to >> check the length of the vector that was allocated. >> >> What happens if a new file was added to the file system between the >> call to count_files() and list_files()? Doesn't this write past the >> length of the allocated vector? > > Good catch. I've added a length check to prevent a problem. > > Cheers, > > + seth > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list_files() memory corruption?
On 3/15/10 8:37 PM, Alistair Gee wrote: > I think I have a fix that avoids the problem by just growing the > vector as necessary as the directory is traversed (and no longer uses > count_lines()). > > I don't have access to the code at the moment, but I should be able to > post the patch tomorrow. Is there interest in my patch? I'm curious to know if this is a problem you have encountered while using R. My initial thought is that there isn't much benefit of making this part of the code smarter. If your patch simplifies things, I'd be more interested. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
