Re: [Rd] S4 Method Signatures
Ah, nevermind. I realised you could have function(...) as the function signature in the setGeneric call. -- View this message in context: http://r.789695.n4.nabble.com/S4-Method-Signatures-tp2525018p2525216.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
Re: [Rd] S4 Method Signatures
DS == Dario Strbenac d.strbe...@garvan.org.au
on Fri, 3 Sep 2010 12:00:14 +1000 (EST) writes:
DS Hello,
DS If the signature of a method defines which generic it implements then
I'm confused about why this minimal example I invented won't work :
very short answer:
if(FALSE) { 0 == 1 }
slightly longer:
if( something_wrong ) { anything_can_be_put_here }
In other words:
Your assumption is wrong.
There's only one generic and potentially many methods, defined
via signatures, but you have not understood what a signature is.
DS setGeneric(myFun, function(rs, ...){standardGeneric(myFun)})
DS setGeneric(myFun, function(cs, ...){standardGeneric(myFun)})
DS setMethod(myFun, numeric, function(rs, colour = Blue)
DS {
DS cat(rs*100, colour)
DS })
DS setMethod(myFun, character, function(cs, colour = Red)
DS {
DS cat(cs, colour)
DS })
Rather:
setGeneric(myFun, function(x, ...) standardGeneric(myFun))
setMethod(myFun, numeric,
function(x, colour = Blue) cat(xs*100, colour))
## etc
where the last is an abbreviated form of
setMethod(myFun, signature(x = numeric),
function(x, colour = Blue) cat(xs*100, colour))
which is abbreviated for
setMethod(myFun, signature = signature(x = numeric),
function(x, colour = Blue) cat(xs*100, colour))
I do wonder why the examples on the ?setMethod
help page where not sufficient here..
DS Thanks for any tips,
you're welcome.
Martin Maechler, ETH Zurich
DS --
DS Dario Strbenac
DS Research Assistant
DS Cancer Epigenetics
DS Garvan Institute of Medical Research
DS Darlinghurst NSW 2010
DS Australia
DS __
DS R-devel@r-project.org mailing list
DS https://stat.ethz.ch/mailman/listinfo/r-devel
DS == Dario Strbenac d.strbe...@garvan.org.au
on Fri, 3 Sep 2010 12:00:14 +1000 (EST) writes:
DS Hello, If the signature of a method defines which
DS generic it implements then I'm confused about why this
DS minimal example I invented won't work :
DS setGeneric(myFun, function(rs,
DS ...){standardGeneric(myFun)}) setGeneric(myFun,
DS function(cs, ...){standardGeneric(myFun)})
DS setMethod(myFun, numeric, function(rs, colour =
DS Blue) { cat(rs*100, colour) })
DS setMethod(myFun, character, function(cs, colour =
DS Red) { cat(cs, colour) })
DS Thanks for any tips, Dario.
DS -- Dario Strbenac
DS Research Assistant Cancer Epigenetics Garvan Institute
DS of Medical Research Darlinghurst NSW 2010 Australia
DS __
DS R-devel@r-project.org mailing list
DS https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Weird erratic error and illogical error message, could someone explain this?
Hello, It's several days I try to track this bug, and even cannot cook a reproducible example. Yet, it occurs consistently in a long-running task after a variable period of time. Here is an example: ... my long-running code [as I said, cannot give something simple that produces this bug in a reproducible manner] Error in match(x, table, nomatch = 0L) : formal argument nomatch matched by multiple actual arguments traceback() 6: match(x, table, nomatch = 0L) 5: factor %in% attrib[[class, exact = TRUE]] 4: structure(.Internal(Sys.time()), class = c(POSIXt, POSIXct)) 3: Sys.time() 2: chemTrigger() at chemostat_1.0-1.R#1132 1: chemRun() So, the culprid is a call inside `%in%` (from within structure() in Sys.time()). But I can run millions times `%in%`, or structure(), or Sys.time() on my machine without producing this bug. Arguments at 5: are simple character strings. They don't hurt! Also, I am lost because the message is totally illogical in the context where it appears: I can understand this message here: match(1, 2, nomatch = 0L, nomatch = NA) Error in match(1, 2, nomatch = 0L, nomatch = NA) : formal argument nomatch matched by multiple actual arguments or here: test - function (...) match(1, ..., nomatch = 0L) test(2, nomatch = NA) Error in match(1, ..., nomatch = 0L) : formal argument nomatch matched by multiple actual arguments but in the call match(x, table, nomatch = 0L) where x is the character string factor and table is another character string (numeric) extracted from a list, I don't understand why it produces this error message. '.Internal(Sys.time())' uses do_systime c code that returns a one-element double... not something that can hurt here?! Can someone explain me, or give me an example where an argument is NOT duplicated in the call (well, as I understand it here) and where one gets such an error message? And why? Many thanks, I am desperate :-( I got this error on R 2.11.1 on Mac OS X 10.6.4, and on R 2.10.1 on Windows XP SP3 (but it does not matter, since I cannot cook a reproducible example). Philippe P.S.: seems related to this: http://finzi.psych.upenn.edu/Rhelp10/2008-June/165101.html -- ..°})) ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons University, Belgium ( ( ( ( ( .. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Stats not loaded? Method for as.ts() results in error
Dear list, I've got the following problem: In a package I'm trying to build, there exists a method for the function as.ts(). When checking the package, R always throws the error that it cannot find a function called as.ts. To me it seems that the package stats (home of as.ts()) is not loaded during the checking process even though it's a base package. For testing, I've written a method for plot() to see if it's a general problem with base-functions, but this one passes just fine. Did anyone of encounter a similar problem or could help me out with a hint? Thank you very much, Janko __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
Philippe Grosjean wrote: Hello, It's several days I try to track this bug, and even cannot cook a reproducible example. Yet, it occurs consistently in a long-running task after a variable period of time. Here is an example: I would look closely at the other software that is running in your long example. Does it include C (or other external) code? Look closely at that, it might be writing outside it's own allocated memory. Also check for correct protection of intermediate results, if you're producing SEXPs in the external code. (Running under gctorture might flush out the bug more quickly if the latter is the problem.) If you're only running R code, then this looks like a bug in R, but it might still be worth trying gctorture to make it reproducible. We won't be able to fix it if we can't reproduce it. Duncan Murdoch ... my long-running code [as I said, cannot give something simple that produces this bug in a reproducible manner] Error in match(x, table, nomatch = 0L) : formal argument nomatch matched by multiple actual arguments traceback() 6: match(x, table, nomatch = 0L) 5: factor %in% attrib[[class, exact = TRUE]] 4: structure(.Internal(Sys.time()), class = c(POSIXt, POSIXct)) 3: Sys.time() 2: chemTrigger() at chemostat_1.0-1.R#1132 1: chemRun() So, the culprid is a call inside `%in%` (from within structure() in Sys.time()). But I can run millions times `%in%`, or structure(), or Sys.time() on my machine without producing this bug. Arguments at 5: are simple character strings. They don't hurt! Also, I am lost because the message is totally illogical in the context where it appears: I can understand this message here: match(1, 2, nomatch = 0L, nomatch = NA) Error in match(1, 2, nomatch = 0L, nomatch = NA) : formal argument nomatch matched by multiple actual arguments or here: test - function (...) match(1, ..., nomatch = 0L) test(2, nomatch = NA) Error in match(1, ..., nomatch = 0L) : formal argument nomatch matched by multiple actual arguments but in the call match(x, table, nomatch = 0L) where x is the character string factor and table is another character string (numeric) extracted from a list, I don't understand why it produces this error message. '.Internal(Sys.time())' uses do_systime c code that returns a one-element double... not something that can hurt here?! Can someone explain me, or give me an example where an argument is NOT duplicated in the call (well, as I understand it here) and where one gets such an error message? And why? Many thanks, I am desperate :-( I got this error on R 2.11.1 on Mac OS X 10.6.4, and on R 2.10.1 on Windows XP SP3 (but it does not matter, since I cannot cook a reproducible example). Philippe P.S.: seems related to this: http://finzi.psych.upenn.edu/Rhelp10/2008-June/165101.html __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Stats not loaded? Method for as.ts() results in error
Janko Thyson wrote: Dear list, I've got the following problem: In a package I'm trying to build, there exists a method for the function as.ts(). When checking the package, R always throws the error that it cannot find a function called as.ts. To me it seems that the package stats (home of as.ts()) is not loaded during the checking process even though it's a base package. For testing, I've written a method for plot() to see if it's a general problem with base-functions, but this one passes just fine. Are you using a NAMESPACE, and declaring your method as a method? If you don't, R will have to guess what the methods are, and it might be getting mixed up because of the unusual name of the generic. Duncan Murdoch Did anyone of encounter a similar problem or could help me out with a hint? Thank you very much, 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
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
Thank you, Duncan for your answer. Indeed, I have also tcltk loaded and running, and the memory allocation problem may come from there. I'll investigate using gctorture(). For sure, I know that I need a reproducible example for further investigations. Best, Philippe ..°})) ) ) ) ) ) ( ( ( ( (Prof. Philippe Grosjean ) ) ) ) ) ( ( ( ( (Numerical Ecology of Aquatic Systems ) ) ) ) ) Mons University, Belgium ( ( ( ( ( .. On 03/09/10 13:42, Duncan Murdoch wrote: Philippe Grosjean wrote: Hello, It's several days I try to track this bug, and even cannot cook a reproducible example. Yet, it occurs consistently in a long-running task after a variable period of time. Here is an example: I would look closely at the other software that is running in your long example. Does it include C (or other external) code? Look closely at that, it might be writing outside it's own allocated memory. Also check for correct protection of intermediate results, if you're producing SEXPs in the external code. (Running under gctorture might flush out the bug more quickly if the latter is the problem.) If you're only running R code, then this looks like a bug in R, but it might still be worth trying gctorture to make it reproducible. We won't be able to fix it if we can't reproduce it. Duncan Murdoch ... my long-running code [as I said, cannot give something simple that produces this bug in a reproducible manner] Error in match(x, table, nomatch = 0L) : formal argument nomatch matched by multiple actual arguments traceback() 6: match(x, table, nomatch = 0L) 5: factor %in% attrib[[class, exact = TRUE]] 4: structure(.Internal(Sys.time()), class = c(POSIXt, POSIXct)) 3: Sys.time() 2: chemTrigger() at chemostat_1.0-1.R#1132 1: chemRun() So, the culprid is a call inside `%in%` (from within structure() in Sys.time()). But I can run millions times `%in%`, or structure(), or Sys.time() on my machine without producing this bug. Arguments at 5: are simple character strings. They don't hurt! Also, I am lost because the message is totally illogical in the context where it appears: I can understand this message here: match(1, 2, nomatch = 0L, nomatch = NA) Error in match(1, 2, nomatch = 0L, nomatch = NA) : formal argument nomatch matched by multiple actual arguments or here: test - function (...) match(1, ..., nomatch = 0L) test(2, nomatch = NA) Error in match(1, ..., nomatch = 0L) : formal argument nomatch matched by multiple actual arguments but in the call match(x, table, nomatch = 0L) where x is the character string factor and table is another character string (numeric) extracted from a list, I don't understand why it produces this error message. '.Internal(Sys.time())' uses do_systime c code that returns a one-element double... not something that can hurt here?! Can someone explain me, or give me an example where an argument is NOT duplicated in the call (well, as I understand it here) and where one gets such an error message? And why? Many thanks, I am desperate :-( I got this error on R 2.11.1 on Mac OS X 10.6.4, and on R 2.10.1 on Windows XP SP3 (but it does not matter, since I cannot cook a reproducible example). Philippe P.S.: seems related to this: http://finzi.psych.upenn.edu/Rhelp10/2008-June/165101.html __ 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] constness in BLAS.h/dger arguments
Hi, I am writing code interfacing R's BLAS functions, and have a problem with two missing const's in the header of F77_NAME(dger) in src/include/R_ext/BLAS.h. The current definition is missing the appropriate consts for the arrays x and y, which are stated in the BLAS documentation [2] to be unchanged on exit. This issue was already mentioned on the list in March 2009 [1], however without any (public) answer from R-core. I have tested the attached patch for this issue in the latest R-patched version and the current release version, and did not encounter any problem during compilation. Since conversion from double* to const double* in a function call is not a problem, I do not think that any external packages could get problems when BLAS.h would be changed in this way. It would be great if this change could make it into the next release version of R. Thanks in advance, Daniel [1] https://stat.ethz.ch/pipermail/r-devel/2009-March/052535.html [2] http://www.netlib.org/lapack/explore-html/a00044_source.html --- src/include/R_ext/BLAS.h.old 2010-09-03 13:49:36.076218165 +0200 +++ src/include/R_ext/BLAS.h 2010-09-03 13:49:52.093173535 +0200 @@ -149,8 +149,8 @@ /* DGER - perform the rank 1 operation A := alpha*x*y' + A */ BLAS_extern void F77_NAME(dger)(const int *m, const int *n, const double *alpha, - double *x, const int *incx, - double *y, const int *incy, + const double *x, const int *incx, + const double *y, const int *incy, double *a, const int *lda); /* DSYR - perform the symmetric rank 1 operation A := alpha*x*x' + A */ BLAS_extern void __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
On 09/03/2010 04:42 AM, Duncan Murdoch wrote: Philippe Grosjean wrote: Hello, It's several days I try to track this bug, and even cannot cook a reproducible example. Yet, it occurs consistently in a long-running task after a variable period of time. Here is an example: I would look closely at the other software that is running in your long example. Does it include C (or other external) code? Look closely at that, it might be writing outside it's own allocated memory. Also check for correct protection of intermediate results, if you're producing SEXPs in the external code. (Running under gctorture might flush out the bug more quickly if the latter is the problem.) If you're only running R code, then this looks like a bug in R, but it might still be worth trying gctorture to make it reproducible. We won't be able to fix it if we can't reproduce it. Duncan Murdoch ... my long-running code [as I said, cannot give something simple that produces this bug in a reproducible manner] Error in match(x, table, nomatch = 0L) : formal argument nomatch matched by multiple actual arguments traceback() 6: match(x, table, nomatch = 0L) 5: factor %in% attrib[[class, exact = TRUE]] 4: structure(.Internal(Sys.time()), class = c(POSIXt, POSIXct)) 3: Sys.time() 2: chemTrigger() at chemostat_1.0-1.R#1132 1: chemRun() I think this is a bug in R that has been fixed in the subversion commit below, and so should be fixed in R-2.11.1. What is your sessionInfo(), and does your error occur in the devel version of R? Martin r51232 | falcon | 2010-03-09 13:59:48 -0800 (Tue, 09 Mar 2010) | 14 lines Changed paths: M /trunk/src/main/match.c Fix bug in matchArgs triggered by gc and finalizers matchArgs was modifying the general purpose bits of SEXPs making up the 'formals' argument to keep track of ARGUSED. When gc is triggered inside matchArgs, finalizer code can end up calling matchArgs on the same function (hence same formals) resulting in corruption of gp bits. This patch uses an int array allocated on the stack to keep track of ARGUSED and avoids modifying the SEXPs in formals. In place modification of SEXPs in supplied still occurs via ARGUSED/SET_ARGUSED, but should be safe as long as no new allocating function calls are added to matchArgs. A reproducible report of this bug was reported here: https://stat.ethz.ch/pipermail/bioc-sig-sequencing/2010-March/000997.html So, the culprid is a call inside `%in%` (from within structure() in Sys.time()). But I can run millions times `%in%`, or structure(), or Sys.time() on my machine without producing this bug. Arguments at 5: are simple character strings. They don't hurt! Also, I am lost because the message is totally illogical in the context where it appears: I can understand this message here: match(1, 2, nomatch = 0L, nomatch = NA) Error in match(1, 2, nomatch = 0L, nomatch = NA) : formal argument nomatch matched by multiple actual arguments or here: test - function (...) match(1, ..., nomatch = 0L) test(2, nomatch = NA) Error in match(1, ..., nomatch = 0L) : formal argument nomatch matched by multiple actual arguments but in the call match(x, table, nomatch = 0L) where x is the character string factor and table is another character string (numeric) extracted from a list, I don't understand why it produces this error message. '.Internal(Sys.time())' uses do_systime c code that returns a one-element double... not something that can hurt here?! Can someone explain me, or give me an example where an argument is NOT duplicated in the call (well, as I understand it here) and where one gets such an error message? And why? Many thanks, I am desperate :-( I got this error on R 2.11.1 on Mac OS X 10.6.4, and on R 2.10.1 on Windows XP SP3 (but it does not matter, since I cannot cook a reproducible example). Philippe P.S.: seems related to this: http://finzi.psych.upenn.edu/Rhelp10/2008-June/165101.html __ 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] Feature request: put NewEnvironment and R_NewhashedEnv into API
What about allocSExp(ENVSXP)? Then SET_ENCLOS() to set the parent? Seems to work for me. Michael On Sun, Aug 29, 2010 at 11:02 AM, Oliver Flasch oliver.fla...@fh-koeln.dewrote: Hi, as Seth Falcon in 2006, I also need to create new environments from package C code. Unfortunately, both NewEnvironment and R_NewHashedEnv are not yet part of the public API, if I understand correctly. Is it planned to add at least one of these functions to the public API in the near future? May I submit a patch? Otherwise I would need to re-implement much of the functionality of R environments in my own code. Many thanks and best regards Oliver -- Dipl. Inform. Oliver Flasch, Institute of Computer Science, Faculty of Computer Science and Engineering Science, Cologne University of Applied Sciences, Steinmüllerallee 1, 51643 Gummersbach phone: +49 171 6447868 eMail: oliver.fla...@fh-koeln.de __ 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] Stats not loaded? Method for as.ts() results in error
Janko, You don't mention if you are using S3 or S4. A small example would make it easier to identify where your problem is. Jeff On Fri, Sep 3, 2010 at 4:44 AM, Janko Thyson janko.thy...@ku-eichstaett.de wrote: Dear list, I've got the following problem: In a package I'm trying to build, there exists a method for the function as.ts(). When checking the package, R always throws the error that it cannot find a function called as.ts. To me it seems that the package stats (home of as.ts()) is not loaded during the checking process even though it's a base package. For testing, I've written a method for plot() to see if it's a general problem with base-functions, but this one passes just fine. Did anyone of encounter a similar problem or could help me out with a hint? Thank you very much, Janko __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Jeffrey Ryan jeff.a.r...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Weird erratic error and illogical error message, could someone explain this?
Martin, This looks like a possible explanation. After double-check, it occurs with R 2.10.1 and 2.11.0 (not 2.11.1, as I reported in my original email). I'll upgrade R and test again. I'll report the results on Monday, since my code has to run over the week-end. Thanks, PhG On 03/09/10 14:53, Martin Morgan wrote: On 09/03/2010 04:42 AM, Duncan Murdoch wrote: Philippe Grosjean wrote: Hello, It's several days I try to track this bug, and even cannot cook a reproducible example. Yet, it occurs consistently in a long-running task after a variable period of time. Here is an example: I would look closely at the other software that is running in your long example. Does it include C (or other external) code? Look closely at that, it might be writing outside it's own allocated memory. Also check for correct protection of intermediate results, if you're producing SEXPs in the external code. (Running under gctorture might flush out the bug more quickly if the latter is the problem.) If you're only running R code, then this looks like a bug in R, but it might still be worth trying gctorture to make it reproducible. We won't be able to fix it if we can't reproduce it. Duncan Murdoch ... my long-running code [as I said, cannot give something simple that produces this bug in a reproducible manner] Error in match(x, table, nomatch = 0L) : formal argument nomatch matched by multiple actual arguments traceback() 6: match(x, table, nomatch = 0L) 5: factor %in% attrib[[class, exact = TRUE]] 4: structure(.Internal(Sys.time()), class = c(POSIXt, POSIXct)) 3: Sys.time() 2: chemTrigger() at chemostat_1.0-1.R#1132 1: chemRun() I think this is a bug in R that has been fixed in the subversion commit below, and so should be fixed in R-2.11.1. What is your sessionInfo(), and does your error occur in the devel version of R? Martin r51232 | falcon | 2010-03-09 13:59:48 -0800 (Tue, 09 Mar 2010) | 14 lines Changed paths: M /trunk/src/main/match.c Fix bug in matchArgs triggered by gc and finalizers matchArgs was modifying the general purpose bits of SEXPs making up the 'formals' argument to keep track of ARGUSED. When gc is triggered inside matchArgs, finalizer code can end up calling matchArgs on the same function (hence same formals) resulting in corruption of gp bits. This patch uses an int array allocated on the stack to keep track of ARGUSED and avoids modifying the SEXPs in formals. In place modification of SEXPs in supplied still occurs via ARGUSED/SET_ARGUSED, but should be safe as long as no new allocating function calls are added to matchArgs. A reproducible report of this bug was reported here: https://stat.ethz.ch/pipermail/bioc-sig-sequencing/2010-March/000997.html So, the culprid is a call inside `%in%` (from within structure() in Sys.time()). But I can run millions times `%in%`, or structure(), or Sys.time() on my machine without producing this bug. Arguments at 5: are simple character strings. They don't hurt! Also, I am lost because the message is totally illogical in the context where it appears: I can understand this message here: match(1, 2, nomatch = 0L, nomatch = NA) Error in match(1, 2, nomatch = 0L, nomatch = NA) : formal argument nomatch matched by multiple actual arguments or here: test- function (...) match(1, ..., nomatch = 0L) test(2, nomatch = NA) Error in match(1, ..., nomatch = 0L) : formal argument nomatch matched by multiple actual arguments but in the call match(x, table, nomatch = 0L) where x is the character string factor and table is another character string (numeric) extracted from a list, I don't understand why it produces this error message. '.Internal(Sys.time())' uses do_systime c code that returns a one-element double... not something that can hurt here?! Can someone explain me, or give me an example where an argument is NOT duplicated in the call (well, as I understand it here) and where one gets such an error message? And why? Many thanks, I am desperate :-( I got this error on R 2.11.1 on Mac OS X 10.6.4, and on R 2.10.1 on Windows XP SP3 (but it does not matter, since I cannot cook a reproducible example). Philippe P.S.: seems related to this: http://finzi.psych.upenn.edu/Rhelp10/2008-June/165101.html __ 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pointer to fourteen patches to speed up R
I've continued to work on speeding up R, and now have a collection of fourteen patches, some of which speed up particular functions, and some of which reduce general interpretive overhead. The total speed improvement from these patches is substantial. It varies a lot from one R program to the next, of course, and probably from one machine to the next, but speedups of 25% can be expected in many programs, and sometimes much more (though sometimes less as well). The fourteen patches work for revision r52822 of the development version of R (I haven't check against any changes in the last few days), and also for release 2.11.1. I also wrote a number of timing test programs. I tried posting this message with the patches and test programs attached, but it got held for moderation because it's over 128K. I'll leave it uncancelled, since maybe it's good to archive them here, but in the interim, you can get both the patches and the test programs from http://www.cs.toronto.edu/~radford/R-mods.html I've included below the documentation on what each patch does, which is also in doc in speed-patches.tar. Note that I fixed a few minor bugs along the way. There looks to be scope for more improvements in various parts of the R interpreter that I didn't get to. I'll have to put this on hold for now, however, to spend my time preparing for the coming teaching term. I'd be happy to hear of any comments on these patches, though, including information on how much they speed up typical programs, on various machines. Radford Neal --- These patches to the R source for improving speed were written by Radford M. Neal, Sept. 2010. See the README file for how to install them. Below, I describe these patches (in alphabetical order), indicate what improvement they produce, and also mention any potential issues with using the patch, and bugs that the patches incidently fix. The timing improvements discussed below are what is obtained by applying each patch individually, on an Intel system running Ubuntu Linux with Gcc version 4.2.4. The total improvement from all patches is much bigger, though in a few instances a patch can diminish the effect of another patch, by reducing the magnitude of the inefficiencies that the other patch eliminates. Note though, that the percentage improvement for a given absolute improvement gets bigger as when other patches reduce overall time. For r52822, the total time for all tests in the accompanying speed test suite is 674 seconds. This is reduced to 487 seconds with all patches applied, a reduction of 28%. Particular R programs will, of course, see widely varying reductions depending on what operations they mostly do. patch-dollar Speeds up access to lists, pairlists, and environments using the $ operator. The speedup comes mainly from avoiding the overhead of calling DispatchOrEval if there are no complexities, from passing on the field to extract as a symbol, or a name, or both, as available, and then converting only as necessary, from simplifying and inlining the pstrmatch procedure, and from not translating string multiple times. Relevant timing test script: test-dollar.r This test shows about a 40% decrease in the time needed to extract elements of lists and environments. Changes unrelated to speed improvement: A small error-reporting bug is fixed, illustrated by the following output with r52822: options(warnPartialMatchDollar=TRUE) pl - pairlist(abc=1,def=2) pl$ab [1] 1 Warning message: In pl$ab : partial match of 'ab' to '' Some code is changed at the end of R_subset3_dflt because it seems to be more correct, as discussed in code comments. patch-evalList Speeds up a large number of operations by avoiding allocation of an extra CONS cell in the procedures for evaluating argument lists. Relevant timing test scripts: all of them, but will look at test-em.r On test-em.r, the speedup from this patch is about 5%. patch-fast-base Speeds up lookup of symbols defined in the base environment, by flagging symbols that have a base environment definition recorded in the global cache. This allows the definition to be retrieved quickly without looking in the hash table. Relevant timing test scripts: all of them, but will look at test-em.r On test-em.r, the speedup from this patch is about 3%. Issue: This patch uses the spare bit for the flag. This bit is misnamed, since it is already used elsewhere (for closures). It is possible that one of the gp bits should be used instead. The gp bits should really be divided up for faster access, and so that their present use is apparent in the code. In case this use of the spare bit proves unwise, the patch code is conditional on FAST_BASE_CACHE_LOOKUP being defined at the start of
Re: [Rd] Stats not loaded? Method for as.ts() results in error
Hi Jeff,
sorry for that! I found the problem in the meanwhile. But since I'm always
grateful to get answers from the list, here's what happened:
I have a method for as.ts()
setMethod(f = as.ts, signature = Tsi, definition = function(x, ...)
{
Function body
})
This is the error I always got while running R CMD check
Error in setMethod(f = as.ts, signature = Tsi, definition = function(x,
:
no existing definition for function as.ts
What I was too stupid to see is the fact that as.ts() isn't a generic in the
first place. Yet, I turned it into one somewhere in my code (which I forgot
;-)) and when I tried to debug my code manually I always misleadingly took
it as an innate generic and wondered why R CMD check always complained about
that fact that it couldn't find it.
Regards,
Janko
-Ursprüngliche Nachricht-
Von: Jeff Ryan [mailto:jeff.a.r...@gmail.com]
Gesendet: Freitag, 3. September 2010 15:57
An: Janko Thyson
Cc: r-de...@r-project. org
Betreff: Re: [Rd] Stats not loaded? Method for as.ts() results in error
Janko,
You don't mention if you are using S3 or S4. A small example would
make it easier to identify where your problem is.
Jeff
On Fri, Sep 3, 2010 at 4:44 AM, Janko Thyson
janko.thy...@ku-eichstaett.de wrote:
Dear list,
I've got the following problem:
In a package I'm trying to build, there exists a method for the
function
as.ts(). When checking the package, R always throws the error that
it
cannot find a function called as.ts. To me it seems that the
package
stats (home of as.ts()) is not loaded during the checking process
even
though it's a base package. For testing, I've written a method for
plot()
to see if it's a general problem with base-functions, but this one
passes
just fine.
Did anyone of encounter a similar problem or could help me out with a
hint?
Thank you very much,
Janko
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Jeffrey Ryan
jeff.a.r...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Incorrect formatted output after subtracting non-integer seconds from POSIXt origin
x-as.POSIXct(1970-1-1, tz=UTC)-.5 y-as.POSIXct(1970-1-1, tz=UTC)+.5 x==y [1] FALSE # of course but x and y appear to be the same when formatted, even with extra precision: format(x, format=%Y-%m-%d %H:%M:%OS2) [1] 1970-01-01 00:00:00.50 format(y, format=%Y-%m-%d %H:%M:%OS2) [1] 1970-01-01 00:00:00.50 Formatted output is fine for integral difference points ... x-as.POSIXct(1970-1-1, tz=UTC)-1 y-as.POSIXct(1970-1-1, tz=UTC)+1 format(x, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 23:59:59.00 format(y, format=%Y-%m-%d %H:%M:%OS2) [1] 1970-01-01 00:00:01.00 ... but seems to be a second off for non-integers: format(as.POSIXct(1970-1-1, tz=UTC)-1.5, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 23:59:59.50 # a second later than expected format(as.POSIXct(1970-1-1, tz=UTC)-86400, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 00:00:00.00 # OK format(as.POSIXct(1970-1-1, tz=UTC)-86400.5, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 00:00:00.50 # why after previous time? Bug, or user misunderstanding? R version 2.11.1 (2010-05-31) on Windows Thanks. Dan Murphy [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Incorrect formatted output after subtracting non-integer seconds from POSIXt origin
On Sep 3, 2010, at 7:56 PM, Daniel Murphy wrote: x-as.POSIXct(1970-1-1, tz=UTC)-.5 y-as.POSIXct(1970-1-1, tz=UTC)+.5 x==y [1] FALSE # of course but x and y appear to be the same when formatted, even with extra precision: format(x, format=%Y-%m-%d %H:%M:%OS2) [1] 1970-01-01 00:00:00.50 format(y, format=%Y-%m-%d %H:%M:%OS2) [1] 1970-01-01 00:00:00.50 Formatted output is fine for integral difference points ... x-as.POSIXct(1970-1-1, tz=UTC)-1 y-as.POSIXct(1970-1-1, tz=UTC)+1 format(x, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 23:59:59.00 format(y, format=%Y-%m-%d %H:%M:%OS2) [1] 1970-01-01 00:00:01.00 ... but seems to be a second off for non-integers: format(as.POSIXct(1970-1-1, tz=UTC)-1.5, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 23:59:59.50 # a second later than expected format(as.POSIXct(1970-1-1, tz=UTC)-86400, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 00:00:00.00 # OK format(as.POSIXct(1970-1-1, tz=UTC)-86400.5, format=%Y-%m-%d %H:%M:%OS2) [1] 1969-12-31 00:00:00.50 # why after previous time? Bug, or user misunderstanding? If negative POSIX time is supposed to work then it's a bug in as.POSIXlt(). Now fixed in R-devel (and patched). Cheers, Simon before: str(unclass(as.POSIXlt(as.POSIXct(1970-1-1, tz=UTC)-0.2))) List of 9 $ sec : num 0.8 $ min : int 0 $ hour : int 0 $ mday : int 1 $ mon : int 0 $ year : int 70 $ wday : int 4 $ yday : int 0 $ isdst: int 0 - attr(*, tzone)= chr UTC R-devel: str(unclass(as.POSIXlt(as.POSIXct(1970-1-1, tz=UTC)-0.2))) List of 9 $ sec : num 59.8 $ min : int 59 $ hour : int 23 $ mday : int 31 $ mon : int 11 $ year : int 69 $ wday : int 3 $ yday : int 364 $ isdst: int 0 - attr(*, tzone)= chr UTC R version 2.11.1 (2010-05-31) on Windows Thanks. Dan Murphy [[alternative HTML version deleted]] __ 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] Incorrect formatted output after subtracting non-integer seconds from POSIXt origin
Thanks. Yes, negative POSIX time would correspond to dates prior to 1970-1-1, or to dates prior to a more recent origin that borrows functionality from the POSIXt class: as.POSIXct(-.5, origin=as.POSIXct(2011-1-1)). If negative POSIX time is supposed to work then it's a bug in as.POSIXlt(). Now fixed in R-devel (and patched). Cheers, Simon before: str(unclass(as.POSIXlt(as.POSIXct(1970-1-1, tz=UTC)-0.2))) List of 9 $ sec : num 0.8 $ min : int 0 $ hour : int 0 $ mday : int 1 $ mon : int 0 $ year : int 70 $ wday : int 4 $ yday : int 0 $ isdst: int 0 - attr(*, tzone)= chr UTC R-devel: str(unclass(as.POSIXlt(as.POSIXct(1970-1-1, tz=UTC)-0.2))) List of 9 $ sec : num 59.8 $ min : int 59 $ hour : int 23 $ mday : int 31 $ mon : int 11 $ year : int 69 $ wday : int 3 $ yday : int 364 $ isdst: int 0 - attr(*, tzone)= chr UTC R version 2.11.1 (2010-05-31) on Windows Thanks. Dan Murphy [[alternative HTML version deleted]] __ 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
