From rgentlem at fhcrc.org  Fri Mar  4 17:13:46 2005
From: rgentlem at fhcrc.org (Robert Gentleman)
Date: Fri Mar  4 17:14:05 2005
Subject: [Rd] eapply weirdness/bug
In-Reply-To: <Pine.LNX.4.61.0502201056060.6368@itasca2.stat.uiowa.edu>
References: <4D99275E380CA94F998977EDACE548DC074AAC@extas2-hba.tas.csiro.au>
	<x2vf8q5k3a.fsf@biostat.ku.dk>
	<Pine.LNX.4.61.0502180821170.3177@itasca2.stat.uiowa.edu>
	<x23bvtdha6.fsf@biostat.ku.dk>
	<Pine.LNX.4.61.0502181029410.7043@nokomis.stat.uiowa.edu>
	<x2vf8ojasn.fsf@biostat.ku.dk>
	<Pine.LNX.4.61.0502201056060.6368@itasca2.stat.uiowa.edu>
Message-ID: <6331774F-8CC8-11D9-8AEC-000D933DC9FE@fhcrc.org>

This should be fixed in the most recent archives - it will take some  
time to propagate
(the .Internal version has been retained )

On Feb 20, 2005, at 8:58 AM, Luke Tierney wrote:

> On Sat, 20 Feb 2005, Peter Dalgaard wrote:
>
>> Luke Tierney <luke@stat.uiowa.edu> writes:
>>
>>> For this specific case though, I _think_ the semantics we want is  
>>> this:
>>>
>>>      eapply1 <- function(env, FUN, ..., all.names = FALSE) {
>>>  	FUN <- match.fun(FUN)
>>>  	lapply(.Internal(env2list(env, all.names)), FUN, ...)
>>>      }
>>>
>>> Not passing the ... in the current implementation is, I think, an
>>> oversight, as is the extra evaluation that occurs.  Given that lapply
>>> is already internal I'm not sure there really is very much benefit in
>>> having the internal eapply.  If not I'd prefer to replace it by
>>> something like this; if there are reasons for keeping the .Internal  
>>> we
>>> can work on replicating these semantics as closely as possible.  I
>>> think Robert is the one who would know the issues.
>>
>> I agree on the semantics (I didn't quite think of the consequences of
>> FUN doing an eval.parent and things like that before). But if
>> implemented literally, wouldn't that env2list cause some undesirable
>> copying? I have the impression that people interested in eapply use
>> their environments to hold some pretty large objects. So maybe we
>> should stick with the get()-based version
>>
>>      eapply2 <- function(env, FUN, ..., all.names = FALSE) {
>>       FUN <- match.fun(FUN)
>>       nm <- ls(envir=env,all.names=all.names)
>>       FUN2 <- function(name,...)FUN(get(name),...)
>>       lapply(nm, FUN2, ...)
>>      }
>
> The copying issue is a good point--Robert also reminded me of this.  I
> _think_ the approach based on env2list would be OK but I'd have to
> check very caerfully to be sure.  Rather than spend time doing that I
> think this argues for keeping the .Internal varsion and modifying it
> to obtain the semantics we want.  I'll look into that.
>
> luke
>
> --  
> Luke Tierney
> University of Iowa                  Phone:             319-335-3386
> Department of Statistics and        Fax:               319-335-3017
>    Actuarial Science
> 241 Schaeffer Hall                  email:      luke@stat.uiowa.edu
> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
>
> ______________________________________________
> R-devel@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
+----------------------------------------------------------------------- 
----------------+
| Robert Gentleman              phone: (206) 667-7700                    
          |
| Head, Program in Computational Biology   fax:  (206) 667-1319   |
| Division of Public Health Sciences       office: M2-B865               
       |
| Fred Hutchinson Cancer Research Center                                 
          |
| email: rgentlem@fhcrc.org                                              
                          |
+----------------------------------------------------------------------- 
----------------+


[Rd] eapply weirdness/bug
Robert Gentleman