Re: [Rd] iterated lapply
On Mo, 2015-02-23 at 16:54 -0500, Duncan Murdoch wrote:
> This is a feature: it allows you to have arguments that are never
> evaluated, because they are never used, or defaults that depend on
> things that are calculated within the function.
I haven't thought about the thing with the default arguments. That's
really a feature.
Thanks,
Daniel
>
> Duncan Murdoch
>
>
> > conditions <- 1:4
> > test <- lapply(conditions, function(mycondition){
> > #print(mycondition)
> > myfn <- function(i) mycondition*i
> > return(myfn)
> > })
> >
> > sapply(test, function(myfn) myfn(2))
> >
> >
> >
> > Cheers,
> > Daniel
> >
>
--
Daniel Kaschek
Institute of Physics
Freiburg University
Room 210
Phone: +49 761 2038531
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] iterated lapply
From: Daniel Kaschek
> ... When I evaluate this list of functions by
> another lapply/sapply, I get an unexpected result: all values coincide.
> However, when I uncomment the print(), it works as expected. Is this a
> bug or a feature?
>
> conditions <- 1:4
> test <- lapply(conditions, function(mycondition){
> #print(mycondition)
> myfn <- function(i) mycondition*i
> return(myfn)
> })
>
> sapply(test, function(myfn) myfn(2))
From: Jeroen Ooms
> I think it is a bug. If we use substitute to inspect the promise, it
> appears the index number is always equal to its last value:
From: Duncan Temple Lang
> Not a bug, but does surprise people. It is lazy evaluation.
I think it is indeed a bug. The lapply code saves a bit of time by
reusing the same storage for the scalar index number every iteration.
This amounts to modifying the R code that was used for the previous
function call. There's no justification for doing this in the
documentation for lapply. It is certainly not desired behaviour,
except in so far as it allows a slight savings in time (which is
minor, given the time that the function call itself will take).
Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] iterated lapply
The documentation is not specific enough on the indented semantics in
this situation to consider this a bug. The original R-level
implementation of lapply was
lapply <- function(X, FUN, ...) {
FUN <- match.fun(FUN)
if (!is.list(X))
X <- as.list(X)
rval <- vector("list", length(X))
for(i in seq(along = X))
rval[i] <- list(FUN(X[[i]], ...))
names(rval) <- names(X) # keep `names' !
return(rval)
}
and the current internal implementation is consistent with this. With
a loop like this lazy evaluation and binding assignment interact in
this way; the force() function was introduced to help with this.
That said, the expression FUN(X[[i]], ...) could be replaced by
local({
i <- i
list(FUN(X[[i]], ...)
})
which would produce the more desirable result
> sapply(test, function(myfn) myfn(2))
[1] 2 4 6 8
The C implementation could use this approach, or could rebuild the
expression being evaluated at each call to get almost the same semantics.
Both would add a little overhead. Some code optimization might reduce
the overhead in some instances (e.g. if FUN is a BUILTIN), but it's
not clear that would be worth while.
Variants of this issue arise in a couple of places so it may be worth
looking into.
Best,
luke
On Tue, 24 Feb 2015, Radford Neal wrote:
From: Daniel Kaschek
... When I evaluate this list of functions by
another lapply/sapply, I get an unexpected result: all values coincide.
However, when I uncomment the print(), it works as expected. Is this a
bug or a feature?
conditions <- 1:4
test <- lapply(conditions, function(mycondition){
#print(mycondition)
myfn <- function(i) mycondition*i
return(myfn)
})
sapply(test, function(myfn) myfn(2))
From: Jeroen Ooms
I think it is a bug. If we use substitute to inspect the promise, it
appears the index number is always equal to its last value:
From: Duncan Temple Lang
Not a bug, but does surprise people. It is lazy evaluation.
I think it is indeed a bug. The lapply code saves a bit of time by
reusing the same storage for the scalar index number every iteration.
This amounts to modifying the R code that was used for the previous
function call. There's no justification for doing this in the
documentation for lapply. It is certainly not desired behaviour,
except in so far as it allows a slight savings in time (which is
minor, given the time that the function call itself will take).
Radford Neal
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] iterated lapply
> On Feb 24, 2015, at 10:50 AM, wrote:
>
> The documentation is not specific enough on the indented semantics in
> this situation to consider this a bug. The original R-level
> implementation of lapply was
>
>lapply <- function(X, FUN, ...) {
>FUN <- match.fun(FUN)
>if (!is.list(X))
>X <- as.list(X)
>rval <- vector("list", length(X))
>for(i in seq(along = X))
>rval[i] <- list(FUN(X[[i]], ...))
>names(rval) <- names(X) # keep `names' !
>return(rval)
>}
>
> and the current internal implementation is consistent with this. With
> a loop like this lazy evaluation and binding assignment interact in
> this way; the force() function was introduced to help with this.
>
> That said, the expression FUN(X[[i]], ...) could be replaced by
>
>local({
>i <- i
>list(FUN(X[[i]], ...)
>})
>
> which would produce the more desirable result
>
>> sapply(test, function(myfn) myfn(2))
>[1] 2 4 6 8
>
Would the same semantics be applied to parallel::mclapply and friends?
sapply(lapply(1:4, function(c){function(i){c*i}}), function(f) f(2))
# [1] 8 8 8 8
sapply(mclapply(1:4, function(c){function(i){c*i}}), function(f) f(2))
# [1] 6 8 6 8
I understand why they differ, but making mclapply easier for 'drop-in'
parallelism might be a good thing.
Michael
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] alternatives to do.call() when namespace is attached but not loaded?
Dear R-devel
I have a function in a package that essentially provides a wrapper for a
group of functions in another Suggested package (it sets appropriate
defaults for the context, transforms output, etc). I've implemented
this by verifying that the package was loaded with
require(sna)
and then
do.call(snaFunName, args = args)
The rDevel check is requesting that I use requireNamespace(sna) instead
of directly loading the SNA package. This seems reasonable, except that
I have yet to figure out a way to use do.call to call the function when
the namespace is attached but package is not loaded.
do.call("sna::funName",..) doesn't seem to work.
1) Can do.call() call functions that are only namespace attached? Is
there better way to accomplish this without do.call()? For example,
should I use getAnywhere('funName') ('tho this doesn't seem to permit
restricting search to a specific namespace..)
2) Is this an appropriate of require() instead of requireNamespace() to
ensure that the Suggested package is loaded and attached? Can I ignore
the check warning?
best,
-skye
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] alternatives to do.call() when namespace is attached but not loaded?
First, a clarification of terminology: a package can be loaded and
attached, or loaded and not attached. It can't be attached and not loaded.
To get the function from a package by name, you could do something like:
getExportedValue("sna", snaFunName)
where snaFunName is a string containing the name of the function.
-Winston
On Tue, Feb 24, 2015 at 12:29 PM, Skye Bender-deMoll
wrote:
> Dear R-devel
>
> I have a function in a package that essentially provides a wrapper for a
> group of functions in another Suggested package (it sets appropriate
> defaults for the context, transforms output, etc). I've implemented this
> by verifying that the package was loaded with
>
> require(sna)
>
> and then
>
> do.call(snaFunName, args = args)
>
>
> The rDevel check is requesting that I use requireNamespace(sna) instead
> of directly loading the SNA package. This seems reasonable, except that I
> have yet to figure out a way to use do.call to call the function when the
> namespace is attached but package is not loaded. do.call("sna::funName",..)
> doesn't seem to work.
>
> 1) Can do.call() call functions that are only namespace attached? Is there
> better way to accomplish this without do.call()? For example, should I use
> getAnywhere('funName') ('tho this doesn't seem to permit restricting search
> to a specific namespace..)
>
> 2) Is this an appropriate of require() instead of requireNamespace() to
> ensure that the Suggested package is loaded and attached? Can I ignore the
> check warning?
>
> best,
> -skye
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] alternatives to do.call() when namespace is attached but not loaded?
do.call(sna::snaFunName, args = args)
?
Hadley
On Tue, Feb 24, 2015 at 1:29 PM, Skye Bender-deMoll
wrote:
> Dear R-devel
>
> I have a function in a package that essentially provides a wrapper for a
> group of functions in another Suggested package (it sets appropriate
> defaults for the context, transforms output, etc). I've implemented this by
> verifying that the package was loaded with
>
> require(sna)
>
> and then
>
> do.call(snaFunName, args = args)
>
>
> The rDevel check is requesting that I use requireNamespace(sna) instead of
> directly loading the SNA package. This seems reasonable, except that I have
> yet to figure out a way to use do.call to call the function when the
> namespace is attached but package is not loaded. do.call("sna::funName",..)
> doesn't seem to work.
>
> 1) Can do.call() call functions that are only namespace attached? Is there
> better way to accomplish this without do.call()? For example, should I use
> getAnywhere('funName') ('tho this doesn't seem to permit restricting search
> to a specific namespace..)
>
> 2) Is this an appropriate of require() instead of requireNamespace() to
> ensure that the Suggested package is loaded and attached? Can I ignore the
> check warning?
>
> best,
> -skye
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] alternatives to do.call() when namespace is attached but not loaded?
> On 24 Feb 2015, at 19:53 , Hadley Wickham wrote:
>
> do.call(sna::snaFunName, args = args)
>
> ?
>
I was about to suggest something similar. The key is that the first arg to
do.call is not necessarily a text string; it can be the actual function object.
So something along the lines of
name <- as.name("snaFunName")
f <- eval(bquote(sna::.(name)))
do.call(f, args)
should work too.
> Hadley
>
> On Tue, Feb 24, 2015 at 1:29 PM, Skye Bender-deMoll
> wrote:
>> Dear R-devel
>>
>> I have a function in a package that essentially provides a wrapper for a
>> group of functions in another Suggested package (it sets appropriate
>> defaults for the context, transforms output, etc). I've implemented this by
>> verifying that the package was loaded with
>>
>> require(sna)
>>
>> and then
>>
>> do.call(snaFunName, args = args)
>>
>>
>> The rDevel check is requesting that I use requireNamespace(sna) instead of
>> directly loading the SNA package. This seems reasonable, except that I have
>> yet to figure out a way to use do.call to call the function when the
>> namespace is attached but package is not loaded. do.call("sna::funName",..)
>> doesn't seem to work.
>>
>> 1) Can do.call() call functions that are only namespace attached? Is there
>> better way to accomplish this without do.call()? For example, should I use
>> getAnywhere('funName') ('tho this doesn't seem to permit restricting search
>> to a specific namespace..)
>>
>> 2) Is this an appropriate of require() instead of requireNamespace() to
>> ensure that the Suggested package is loaded and attached? Can I ignore the
>> check warning?
>>
>> best,
>> -skye
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
> --
> http://had.co.nz/
>
> __
> 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
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
