similar to: 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 to [lsv]apply()? Something that would allow you to write: sapply(split(mtcars, mtcars$cyl), F(summary(lm(mpg ~ wt,.))$r.squared)) Such an F() function would apply elsewhere too. /Henrik On Thu, Apr 16, 2020 at 9:30 AM

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 with a correct proposal for this principle? Meanwhile, to avoid substitute(),

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 <sokol at insa-toulouse.fr> >> wrote: Hi, I would like to make a

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 but this implementation has similar flaws pointed by Simon, i.e. it reduces

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 functions. If the only free variables are the arguments to the function then you can omit the left

This syntax is already implemented in the {purrr} package, more or less -- you need to add a tilde before your function call for it to work exactly as written: purrr::map_dbl(split(mtcars, mtcars$cyl), ~ summary(lm(wt ~ mpg, .))$r.squared) is equivalent to sapply(split(mtcars, mtcars$cyl), function(d) summary(lm(mpg ~ wt, d))$r.squared) Seems like using this package is probably an easier

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 sapply(x, (foo)) is completely valid so you can't just change the evaluation of the expression to

Serguei, > On 17/04/2020, at 2:24 AM, Sokol Serguei <sokol at insa-toulouse.fr> 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 surround them. The argument to the anonymous function is

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(s))" [[2]] [1] "2 : paste(., \":\",

Le 22/01/2018 ? 17:40, Keith O'Hara a ?crit?: > This behavior is noted in the qr documentation, no? > > rank - the rank of x as computed by the decomposition(*): always full rank in the LAPACK case. For a me a "full rank matrix" is a matrix the rank of which is indeed min(nrow(A), ncol(A)) but here the meaning of "always is full rank" is somewhat confusing. Does it

Le 23/01/2018 ? 08:47, Martin Maechler a ?crit?: >>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>>> on Mon, 22 Jan 2018 17:57:47 +0100 writes: > > Le 22/01/2018 ? 17:40, Keith O'Hara a ?crit?: > >> This behavior is noted in the qr documentation, no? > >> > >> rank - the rank of x as

Le 05/07/2017 ? 13:09, Duncan Murdoch a ?crit : > On 05/07/2017 5:26 AM, January W. wrote: >> I tried the newest patch, but it does not seem to work for me (on >> Linux). Despite the check in Rconn_printf, the write.csv happily writes >> to /dev/full and does not report an error. When I added a printf("%d\n", >> res); to the Rconn_printf() definition, I see

Hi, I have noticed different rank values calculated by qr() depending on LAPACK parameter. When it is FALSE (default) a true rank is estimated and returned. Unfortunately, when LAPACK is set to TRUE, the min(nrow(A), ncol(A)) is returned which is only occasionally a true rank. Would not it be more consistent to replace the rank in the latter case by something based on the following pseudo code ?

Here is an attached patch. Best, Serguei. Le 29/05/2017 ? 12:21, Serguei Sokol a ?crit : > The problem or actual R implementation relies on an assumption > that median(x[i] | x[i] <= quantile(x, 1/3)) == quantile(x, 1/6) > which reveals not to be true despite very trustful appearance. > > If we continue with the example of x=y=1:9 > then quantile(x, 1/6)=2.5 (here quantile()

Le 10/01/2023 ? 11:37, Serguei Sokol a ?crit?: > Le 10/01/2023 ? 10:44, RICHET Yann a ?crit?: >> Dear R-devel people, >> >> We are working to submit a package which is mainly a binding over a >> C++ lib (https://github.com/libKriging) using armadillo. >> It is _not_ a standard RcppArmadillo package, because we also had to >> provide a python binding... so

Seriously, if a method gives a wrong result, it's wrong. line() does NOT implement the algorithm of Tukey, even not after the patch. We're not discussing Excel here, are we? The method of Tukey is rather clear, and it is NOT using the default quantile definition from the quantile function. Actually, it doesn't even use quantiles to define the groups. It just says that the groups

Le 15/05/2017 ? 15:37, Martin Maechler a ?crit : >>>>>> Serguei Sokol <sokol at insa-toulouse.fr> >>>>>> on Mon, 15 May 2017 13:14:34 +0200 writes: > > I see in the archives that the attachment cannot pass. > > So, here is the code: > > [....... MM: I needed to reformat etc to match closely to > the current

Le 10/01/2023 ? 10:44, RICHET Yann a ?crit?: > Dear R-devel people, > > We are working to submit a package which is mainly a binding over a C++ lib (https://github.com/libKriging) using armadillo. > It is _not_ a standard RcppArmadillo package, because we also had to provide a python binding... so there is a huge layer of cmake & scripting to make it work with a standard armadillo

Hi, I came across a case when the dimensions of matrices returned by qr() operated on a sparse matrix does not coincide with the initial matrix. Here is a spinet code that should produce an example (one of many that I could provide): ?m=205 ?n=199 ?set.seed(7); ?a=matrix(rnorm(m*n), m, n) ?a[sample(seq(m*n), m*(n-4))]=0 ?a=as(a, "Matrix") ?qa=qr(a); ?stopifnot(nrow(qa at R) ==

Le 04/12/2018 ? 11:27, I?aki Ucar a ?crit?: > On Tue, 4 Dec 2018 at 11:12, <qweytr1 at mail.ustc.edu.cn> wrote: >> function ppois is a function calculate the CDF of Poisson distribution, it should generate a non-decreasing result, but what I got is: >> >>> any(diff(ppois(0:19,lambda=0.9))<0) >> [1] TRUE >> >> Actually, >> >>>