[R] Summary: do.call and environments

Spencer Graves spencer.graves at pdf.com
Thu Mar 11 09:28:35 CET 2004


      That looks great, but I'm confused.  In R 1.8.1 under Windows 
2000, the suggested script produced for me the following:

 > f("fx",2)
[1] 6

      I would have naively expected 14.  From whence cometh "6"? 

      Also, I prefer to use transportable code wherever feasible.  The 
same script generated the following response from S-Plus 6.2: 

 > f("fx", 2)
Problem in f("fx", 2): Couldn't find a function definition for 
"environment"
Use traceback() to see the call stack

      Thanks,
      Spencer Graves

Gabor Grothendieck wrote:

>To use the modify the solution from Tony and I 
>so that you can pass the name of the function, rather
>than the function itself, like this:
>
>x <- 7
>fx <- function(y) print(x*y)
>f <- function(fun, x) {
>	 fun <- get(fun)
>         environment(fun) <- environment()
>         do.call("fun",list(3))
>}
>f("fx",2)
>
>
>---
>Date:   Thu, 11 Mar 2004 08:22:45 +0100 
>From:   Thomas Petzoldt <petzoldt at rcs.urz.tu-dresden.de>
>Cc:   <petzoldt at rcs.urz.tu-dresden.de>, <r-help at stat.math.ethz.ch> 
>Subject:   [R] Summary: do.call and environments 
>
> 
>Dear R users,
>
>thank you very much for your suggestions. I've learned much, especially
>that the problem was not as simple as I thought. There have been several
>proposals, but most of them solved the problem only partly.
>
>The proposal(s) of Gabor and Tony (different versions) seemed to be very 
>promising:
>
>  
>
>>fx <- function(y) print(x*y)
>>f <- function(fun, x) {
>>environment(fun) <- environment()
>>fun(3)
>>}
>>f(fx,2)
>>    
>>
>
>... but unfortunately they miss the "do.call" mechanism. I intended to 
>call a function given as character with f("fx", value), and not f(fx, 
>value).
>
>Another proposal (from Robert Gentleman, thank you) works. It has the 
>only disadvantage, that I have to set an environment outside of my own
>function. If I understand this correctly, this means that the new
>environment ist set persistently (*globally*) and may have side-effects 
>to other calls:
>
>  
>
>>fx <- function(y) print(x*y)
>>environment(fx) <- new.env()
>>
>>ff <- function(fun, x) {
>>assign("x", x, environment(get(fun, mode="function")))
>>do.call(fun, list(y=3))
>>}
>>    
>>
>
>Furthermore, Andy pointed out that my idea was a bad one, but why I am 
>trying such weired things? My problem is, that I want to define list 
>objects which contain informations, about how they are processed (as 
>character, not as copy of a function). This solver function (e.g. 
>"lsoda" from the odesolve package) then calls a third function (my model 
>equations), provided from my side again, but unfortunately does not 
>"pass through" some additonal argument(s), needed by the model 
>equations. So I wanted to call lsoda or my own function provided with 
>the additional arguments within an own environment.
>
>Now, as it comes out, that this was really a bad idea, I should focus on 
>the pass-trough method (...) and use one of the 99% workarounds 
>mentioned above in the meantime.
>
>Thank you again
>
>Thomas P.
>
>______________________________________________
>R-help at stat.math.ethz.ch mailing list
>https://www.stat.math.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html
>
>  
>




More information about the R-help mailing list