Re: [R] Summary: do.call and environments

[Spencer Graves]

     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 <[EMAIL PROTECTED]>
Cc:   <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> 
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.

______________________________________________
[EMAIL PROTECTED] 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
 

______________________________________________
[EMAIL PROTECTED] 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