R devel - Oct 2003 - NLME: gls parameter evaluation inconsistency (PR#4757)

Full_Name: W.B.Kloke
Version: 1.8.0
OS: FreeBSD-4.7
Submission from: (NULL) (195.253.22.63)


I found a parameter evaluation inconsistency in NLME package. I tried to use
gls() inside a function, and I wanted use gls() for different subsets of a data
frame:

prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t
,pr,subset=subject==name)}

Applying this function with a string as parameter like prgls("VM")
yields an
error
Error in eval(expr, envir, enclos) : Object "name" not found

The same definition with lm() instead of gls() works fine. Of course I want to
use the correlation features of gls(). It looks like a wrong environment at the
place of subset evaluation (the local variables and function paramaters are not
available). Probably lme(), ngls() and nlme() have the same inconsistency.

wb@arb-phys.uni-dortmund.de writes:
> Full_Name: W.B.Kloke
> Version: 1.8.0
> OS: FreeBSD-4.7
> Submission from: (NULL) (195.253.22.63)
> 
> 
> I found a parameter evaluation inconsistency in NLME package. I tried to
use
> gls() inside a function, and I wanted use gls() for different subsets of a
data
> frame:
> 
> prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t
> ,pr,subset=subject==name)}
> 
> Applying this function with a string as parameter like
prgls("VM")
> yields an error Error in eval(expr, envir, enclos) : Object
"name"
> not found
> 
> The same definition with lm() instead of gls() works fine. Of course
> I want to use the correlation features of gls(). It looks like a
> wrong environment at the place of subset evaluation (the local
> variables and function paramaters are not available). Probably
> lme(), ngls() and nlme() have the same inconsistency.
Yes.  It's the old "standard non-standard evaluation" problem. 
The
model.frame function is (and has to be) very peculiar in the way
that it determines the value of variable names without local
bindings.  That's the non-standard evaluation part.  Because it is
difficult to get this right, it helps if it only needs to be done in
one place so we have what Thomas Lumley described as a "standard
non-standard evaluation" function in the current model.frame function.

However, model.frame expects to have only one argument called
"formula" (the first argument) containing a formula that will need to
be evaluated in the frame.  The model fitting functions in the nlme
package can have formulas in multiple arguments.  Arranging for the
proper call to model.frame to be evaluated is not easy.

A workaround is to use subset on the data frame passed as an argument

prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t
 ,subset(pr,subject==name))}



-- 
Douglas Bates                            bates@stat.wisc.edu
Statistics Department                    608/262-2598
University of Wisconsin - Madison        http://www.stat.wisc.edu/~bates/

> -----Original Message-----
> From: Douglas Bates [mailto:bates@stat.wisc.edu]
> Sent: Friday, October 24, 2003 12:16 PM
[...]
> Yes.  It's the old "standard non-standard evaluation"
problem.  The
> model.frame function is (and has to be) very peculiar in the way
> that it determines the value of variable names without local
> bindings.  That's the non-standard evaluation part.  Because it is
> difficult to get this right, it helps if it only needs to be done in
> one place so we have what Thomas Lumley described as a "standard
> non-standard evaluation" function in the current model.frame function.
> 
> However, model.frame expects to have only one argument called
> "formula" (the first argument) containing a formula that will
need to
> be evaluated in the frame.  The model fitting functions in the nlme
> package can have formulas in multiple arguments.  Arranging for the
> proper call to model.frame to be evaluated is not easy.
> 
> A workaround is to use subset on the data frame passed as an argument
> 
> prgls <- function(name){ gls( log10(Y)~(cond-1)+(cond-1):t
>  ,subset(pr,subject==name))}
Why don't we extend model.frame to allow for multiple 'formula-like'
arguments?  Perhaps by adding an argument that allows the call to specify
which paramters are 'formula-like'?

-G


LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}