local({
a <- 2
df <- data.frame(q = 1:3)
ddply(df, "q", function(piece) {
mutate(piece, r = q / a)
})
})
I have tried to fix it properly once only to fail. lapply works
around the problem by manually constructing and evaluating calls at
the C-level, which I'd really rather avoid.
Hadley
> --
> You received this message because you are subscribed to the Google Groups
> "manipulatr" group.
> To post to this group, send email to manip...@googlegroups.com.
> To unsubscribe from this group, send email to
> manipulatr+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/manipulatr?hl=en.
>
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
ddply() hands down its "..." arguments to alply() and in turn to
llply(). By the time llply() is working, there's no way to tell which
environment the expression "q/a" was defined in.
It's an abstraction breakdown that R suffers when you want to pass
your arguments down to a worker function and that worker function does
nonstandard eval.
I think it could be fixed if there was a way to read off the
environment associated with a promise object. delayedAssign() lets you
construct promises with arbitrary expressions and environments, and
substitute() lets you read off the expressions, so to my mind there's
no reason not to be able to read off the environment.
(I might be characterizing the problem wrong. It's something I only
recently started banging my head against.)
Peter
ddply() hands down its "..." arguments to alply() and in turn to
llply(). By the time llply() is working, there's no way to tell which
environment the expression "q/a" was defined in.
It's an abstraction breakdown that R suffers when you want to pass
your arguments down to a worker function and that worker function does
nonstandard eval.
Well it is possible, but it's tricky - you need to capture the
parent.frame() (not the parent environment) when llply is called, and
then pass that down along the call stack. I've managed to do that.
The challenge is then figuring out how to evaluate the function in the
right context so that it can access the variables in the environment
in which it was called (dynamic scope) as well as the variables
representing the data that's being process (lexical scope). I could
never figure this out.
Hadley
But it's not the enclosing environment - it's the parent (calling)
frame. This is the difference between lexical and dynamic scope.
Hadley
Yes, and that may have been something I tried. But I have the same
problem as you - this isn't really the job I get paid to do, so I have
to minimise the amount of time I spend on it. I'm investigating
business models so that I could hire a programmer to work full-time
for me, but it's likely to be a while before I find both the money and
the right person.