I wouldn't drive my choices using unlikely edge cases
but rather focus on the vast majority of practical cases.
The popularity of tidyverse shows that this philosophy
works well from a user's perspective.
For the vast majority of practical cases it works well, and for the
others you can either us
Le 19/04/2020 à 20:46, Gabor Grothendieck a écrit :
You can get pretty close to that already using fn$ in the gsubfn package:
library(gsubfn) fn$sapply(split(mtcars, mtcars$cyl), x ~
summary(lm(mpg ~ wt, x))$r.squared)
4 6 8 0.5086326 0.4645102 0.4229655
Right, I thought about similar syntax b
You can get pretty close to that already using fn$ in the gsubfn package:
> library(gsubfn)
> fn$sapply(split(mtcars, mtcars$cyl), x ~ summary(lm(mpg ~ wt, x))$r.squared)
4 6 8
0.5086326 0.4645102 0.4229655
It is not specific to sapply but rather fn$ can preface most funct
Thanks Simon,
Now, I see better your argument.
Le 16/04/2020 à 22:48, Simon Urbanek a écrit :
... I'm not arguing against the principle, I'm arguing about your
particular proposal as it is inconsistent and not general.
This sounds promising for me. May be in a (new?) future, R core will
come w
Sergei,
the main problem that I was pointing out is is that there is no way you can
introduce the new syntax without breaking the old one. The expression is
evaluated to obtain a function, so by definition using anything that results in
a valid expression for your syntax will break. E.g., using
$r.squared)
Seems like using this package is probably an easier solution for this
wish than adding a reserved variable and adding additional syntax to
the apply family as a whole.
Thanks,
-Mike
From: Sokol Serguei
Date: Thu, Apr 16, 2020 at 12:03 PM
Subject: Re: [Rd] suggestion: "." in [lsv
Michael Mahoney
> Cc: R-devel
> Subject: Re: [Rd] suggestion: "." in [lsv]apply()
>
> I'm sure this exists elsewhere, but, as a trade-off, could you achieve
> what you want with a separate helper function F(expr) that constructs
> the function you want to pass
this
> wish than adding a reserved variable and adding additional syntax to
> the apply family as a whole.
>
> Thanks,
>
> -Mike
>
> > From: Sokol Serguei
> > Date: Thu, Apr 16, 2020 at 12:03 PM
> > Subject: Re: [Rd] suggestion: "." in [lsv]app
; Subject: Re: [Rd] suggestion: "." in [lsv]apply()
> To: William Dunlap
> Cc: r-devel
>
>
> Thanks Bill,
>
> Clearly, my first proposition for wsapply() is quick and dirty one.
> However, if "." becomes a reserved variable with this new syntax,
> wsa
Thanks Bill,
Clearly, my first proposition for wsapply() is quick and dirty one.
However, if "." becomes a reserved variable with this new syntax,
wsapply() can be fixed (at least for your example and alike) as:
wsapply=function(l, fun, ...) {
.=substitute(fun)
if (is.name(.) || is.cal
Simon,
Thanks for replying. In what follows I won't try to argue (I understood
that you find this a bad idea) but I would like to make clearer some of
your point for me (and may be for others).
Le 16/04/2020 à 16:48, Simon Urbanek a écrit :
Serguei,
On 17/04/2020, at 2:24 AM, Sokol Serguei
Passing in a function passes not only an argument list but also an
environment from which to get free variables. Since your function doesn't
pay attention to the environment you get things like the following.
> wsapply(list(1,2:3), paste(., ":", deparse(s)))
[[1]]
[1] "1 : paste(., \":\", deparse
Serguei,
> On 17/04/2020, at 2:24 AM, Sokol Serguei wrote:
>
> Hi,
>
> I would like to make a suggestion for a small syntactic modification of FUN
> argument in the family of functions [lsv]apply(). The idea is to allow
> one-liner expressions without typing "function(item) {...}" to surroun
Hi,
I would like to make a suggestion for a small syntactic modification of
FUN argument in the family of functions [lsv]apply(). The idea is to
allow one-liner expressions without typing "function(item) {...}" to
surround them. The argument to the anonymous function is simply referred
as "."
14 matches
Mail list logo