On Sun, 1 Mar 2015, luke-tier...@uiowa.edu wrote:
On Thu, 26 Feb 2015, William Dunlap wrote:
...
It also seems to cause problems with some built-in functions:
newlapply <- function (X, FUN, ...)
{
FUN <- match.fun(FUN)
if (!is.list(X))
X <- as.list(X)
rval <- vector("list
On Thu, 26 Feb 2015, William Dunlap wrote:
...
It also seems to cause problems with some built-in functions:
newlapply <- 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)) {
On Sun, 1 Mar 2015, Radford Neal wrote:
There are other instances, such as Reduce where there is a bug
report pending that amounts to the same issue. Performing surgery on
expressions and calling eval is not good practice at the R level and
probably not a good idea at the C level either. It is
> There are other instances, such as Reduce where there is a bug
> report pending that amounts to the same issue. Performing surgery on
> expressions and calling eval is not good practice at the R level and
> probably not a good idea at the C level either. It is worth thinking
> this through care
On Sun, 1 Mar 2015, Radford Neal wrote:
I think the discussion of this issue has gotten more complicated than
necessary.
The discussion has gotten no more complicated than it needs to
be. There are other instances, such as Reduce where there is a bug
report pending that amounts to the same iss
I think the discussion of this issue has gotten more complicated than
necessary.
First, there really is a bug. You can see this also by the fact that
delayed warning messages are wrong. For instance, in R-3.1.2:
> lapply(c(-1,2,-1),sqrt)
[[1]]
[1] NaN
[[2]]
[1] 1.414214
[[3]]
Actually using local() might create some issues, though probably not
many. For the C implementation of lapply I would probably create a new
environment with a frame containing the binding for i and use that in
an eval call. That wouldn't add another call frame, but it would
change the environment
Would introducing the new frame, with the call to local(), cause problems
when you use frame counting instead of <<- to modify variables outside the
scope of lapply's FUN, I think the frame counts may have to change. E.g.,
here is code from actuar::simul() that might be affected:
x <- unl
> Michael Weylandt
> on Wed, 25 Feb 2015 21:43:36 -0500 writes:
>> On Feb 25, 2015, at 5:35 PM, Benjamin Tyner
>> wrote:
>>
>> Actually, it depends on the number of cores:
> Under current semantics, yes. Each 'stream' of function
> calls is lazily capturing
> On Feb 25, 2015, at 5:35 PM, Benjamin Tyner wrote:
>
> Actually, it depends on the number of cores:
Under current semantics, yes. Each 'stream' of function calls is lazily
capturing the last value of `i` on that core.
Under Luke's proposed semantics (IIUC),
the result would be the same (2
Actually, it depends on the number of cores:
> fun1 <- function(c){function(i){c*i}}
> fun2 <- function(f) f(2)
> sapply(mclapply(1:4, fun1, mc.cores=1L), fun2)
[1] 8 8 8 8
> sapply(mclapply(1:4, fun1, mc.cores=2L), fun2)
[1] 6 8 6 8
> sapply(mclapply(1:4, fun1, mc.core
> 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.
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 <- vecto
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(m
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 arg
Use force() (or anything that evaluates mycondition, e.g. your print):
function(mycondition) {
force(mycondition)
function(i) mycondition * i
}
within the lapply() loop.
Not a bug, but does surprise people. It is lazy evaluation.
D.
On 2/23/15 12:57 PM, Daniel Kaschek wrote:
> Hi everyb
On 23/02/2015 3:57 PM, Daniel Kaschek wrote:
> Hi everybody,
>
> with the following code I generate a list of functions. Each function
> reflects a "condition". When I evaluate this list of functions by
> another lapply/sapply, I get an unexpected result: all values coincide.
> However, when I unc
On Mon, Feb 23, 2015 at 12:57 PM, Daniel Kaschek
wrote:
> Is this a bug or a feature?
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:
vec <- c("foo", "bar", "baz")
test <- lapply(vec, function(x){
function(){x}
})
Greetings!
I thought it was a lazy evaluation thing. I added "force" around
mycondition and everything worked as expected.
Cheers!
On Mon Feb 23 2015 at 1:47:20 PM Jeroen Ooms wrote:
> On Mon, Feb 23, 2015 at 12:57 PM, Daniel Kaschek
> wrote:
> > Is this a bug or a feature?
>
> I think it is
Hi everybody,
with the following code I generate a list of functions. Each function
reflects a "condition". 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 o
20 matches
Mail list logo
