In the case of power.t.test, there is a situation where you want to create 4 
different functions with the same function body, in order to pass them to 
uniroot(). I think that at the time, it just seemed convenient to express that 
idea with a quote-eval (macro-like) construction, rather than figure out how to 
do it with functions. I suppose that it could have been done neatly enough 
along the lines of

g <- function(x1, x2, x3, x4)
{
  f <- function(x1, x2, x3, x4) {...body...}
  if (is.null(x1)
     x1 <- uniroot(function(x1) {target - f(x1, x2, x3, x4)}, ....)$root
  ....
}

This adds an extra layer of function call, but probably makes the byte compiler 
happier!

You might also use the ... argument to uniroot() as in

x1 <- uniroot(f, x2=x2, x3=x3, x4=x4, ..other args..)$root

but that gets a bit clunky.

-pd

> On 12 Jul 2023, at 00:01 , Ben Bolker <bbol...@gmail.com> wrote:
> 
>  In a few places in the R source code, such as the $initialize element of 
> `family` objects, and in the body of power.t.test() (possibly other power.* 
> functions), sets of instructions that will need to be run later are 
> encapsulated by saving them as an expression and later applying eval(), 
> rather than as a function. This seems weird to me; the only reason I can 
> think of for doing it this way is to avoid having to pass back multiple 
> objects and assign them in the calling environment (since R doesn't have a 
> particularly nice form of Python's tuple-unpacking idiom).
> 
>  Am I missing something?
> 
> cheers
>   Ben
> 
> 
> https://github.com/r-devel/r-svn/blob/eac72e66a4d2c2aba50867bd80643b978febf5a3/src/library/stats/R/power.R#L38-L52
> 
> https://github.com/r-devel/r-svn/blob/master/src/library/stats/R/family.R#L166-L171
> 
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd....@cbs.dk  Priv: pda...@gmail.com

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to