search for: jmount

...-> plus2 plus2(5) #> Error: C stack usage 15923776 is too close to the limit What I propose on the other hand can always substitute any existing proper pipe in their standard feature, as long as the dot is made explicit. Best regards, Antoine Le sam. 5 oct. 2019 ? 16:59, John Mount <jmount at win-vector.com> a ?crit : > Actually, base R already has a pipe fairly close to the one you describe: > ->.; > > iris ->.; head(.) ->.; dim(.) > # [1] 6 5 > > I've called it the Bizarro pipe ( > http://www.win-vector.com/blog/2016/12/magrittrs-doppelgange...

Thank you for your suggestion. I do know how to work around the issue. I usually build a fresh environment as a child of base-environment and then insurt the weights there. I was just trying to provide an example of the issue. emptyenv() can not be used, as it is needed for the eval (errors out even if weights are not used with "could not find function list"). For some applications

I was wondering if it would make sense to change the default behavior of the following: summary(15555L) ## Min. 1st Qu. Median Mean 3rd Qu. Max. ## 15560 15560 15560 15560 15560 15560 summary.default on numeric values rounds values (not just presentation) to getOption("digits")-3L (or four) digits by default, making those values surprising and less suitable for

...e binomial distributions, but I can't offhand picture a calculation that leads to integer k, n plus/minus a tiny numerical error of the sort that one may encounter with, say, seq(). -pd ;-) choose(a,b) = 1/(beta(a-b+1,b+1)*(a+1)) or thereabouts > On 14 Jan 2020, at 19:36 , John Mount <jmount at win-vector.com> wrote: > > > At the risk of throwing oil on a fire. If we are talking about fractional values of choose() doesn't it make sense to look to the gamma function for the correct analytic continuation? In particular k<0 may not imply the function should evaluate...

...me discussion on its origin and also a declaration of intents to change the default behaviour, which, unfortunately, remained a declaration. I agree that R could do better here, let's hope in less than ten years though. ;-) Kind regards, Simone On Fri, Aug 19, 2016 at 5:04 PM, John Mount <jmount at win-vector.com> wrote: > I was wondering if it would make sense to change the default behavior of > the following: > > summary(15555L) > ## Min. 1st Qu. Median Mean 3rd Qu. Max. > ## 15560 15560 15560 15560 15560 15560 > > summary.default on nume...

...76 is too close to the limit > > What I propose on the other hand can always substitute any existing proper > pipe in their standard feature, as long as the dot is made explicit. > > Best regards, > > Antoine > > > > Le sam. 5 oct. 2019 ? 16:59, John Mount <jmount at win-vector.com> a ?crit : > >> Actually, base R already has a pipe fairly close to the one you describe: >> ->.; >> >> iris ->.; head(.) ->.; dim(.) >> # [1] 6 5 >> >> I've called it the Bizarro pipe ( >> http://www.win-vector.c...

>>>>> Martin Maechler <maechler at stat.math.ethz.ch> >>>>> on Tue, 23 Aug 2016 14:33:58 +0200 writes: >>>>> Dirk Eddelbuettel <edd at debian.org> >>>>> on Fri, 19 Aug 2016 11:40:05 -0500 writes: >> It is the old story of defined behaviour and expected outcomes. Hard to >> change now. >

I wish I had started with "I am disappointed that lm() doesn't continue its search for weights into the calling environment" or "the fact that lm() looks only in the formula environment and data frame for weights doesn't seem consistent with how other values are treated." But I did not. So I do apologize for both that and for negative tone on my part. Simplified

Dear R-devel, The most popular piping operator sits in the package `magrittr` and is used by a huge amount of users, and imported /reexported by more and more packages too. Many workflows don't even make much sense without pipes nowadays, so the examples in the doc will use pipes, as do the README, vignettes etc. I believe base R could have a piping operator so packages can use a pipe in

OK, I see what you mean. But in those cases, we don't get the catastrophic failures from the if (k < 0) return 0.; if (k == 0) return 1.; /* else: k >= 1 */ part, because at that point k is sure to be integer, possibly after rounding. It is when n-k is approximately but not exactly zero and we should return 1, that we either return 0 (negative case) or n

Actually, base R already has a pipe fairly close to the one you describe: ->.; iris ->.; head(.) ->.; dim(.) # [1] 6 5 I've called it the Bizarro pipe ( http://www.win-vector.com/blog/2016/12/magrittrs-doppelganger/ <http://www.win-vector.com/blog/2016/12/magrittrs-doppelganger/> ), and for some reason we chickened out and didn't spend time on it in the dot pipe paper (

I would suggest stats::glm() should set "converged" to FALSE in the return value in a few more situations. I believe the current returned converged == TRUE can be needlessly misleading when the algorithm has clearly failed (and the algo even issued a warning, but the returned structure claims all is well). In particular there are pathological inputs which cause the residual deviance to

Perhaps use the digest package? Isn't "R the R packages?" > On May 1, 2020, at 2:00 PM, D?nes T?th <toth.denes at kogentum.hu> wrote: > > > AFAIK there is no hashing utility in base R which can create hash digests of arbitrary R objects. However, as also described by Henrik Bengtsson in [1], we have tools::md5sum() which calculates MD5 hashes of files.

At the risk of throwing oil on a fire. If we are talking about fractional values of choose() doesn't it make sense to look to the gamma function for the correct analytic continuation? In particular k<0 may not imply the function should evaluate to zero until we get k<=-1. Example: ``` r choose(5, 4) #> [1] 5 gchoose <- function(n, k) { gamma(n+1)/(gamma(n+1-k) * gamma(k+1))

Doesn't this preclude "y ~ ." style notations? > On Aug 9, 2020, at 11:56 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > This is fairly clearly documented in ?lm: > > "All of weights, subset and offset are evaluated in the same way as variables in formula, that is first in data and then in the environment of formula." > > There

I know this programmers can reason this out from R's late parameter evaluation rules PLUS the explicit match.call()/eval() lm() does to work with the passed in formula and data frame. But, from a statistical user point of view this seems to be counter-productive. At best it works as if the user is passing in the name of the weights variable instead of values (I know this is the obvious