Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-20 Thread Sokol Serguei
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

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-20 Thread Gabor Grothendieck
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

Re: [Rd] stringsAsFactors and type.convert()

2020-04-20 Thread Martin Maechler
> Arni Magnusson > on Mon, 13 Apr 2020 22:20:19 + writes: > If read.table() is defaulting to "character" instead of "factor" data type, shouldn't type.convert() also default to "character" in R 4.0.0? > This would seem like a good time to change the default to type.conve

Re: [Rd] stringsAsFactors and type.convert()

2020-04-20 Thread Arni Magnusson
Dear Martin, Thank you for the well-reasoned response. I realized I was rather late to make this suggestion for 4.0.0, changing a somewhat low-level function that can indeed affect packages. I was just reviewing some R user scripts that were using type.convert(), mainly on data frames. In all

Re: [Rd] stringsAsFactors and type.convert()

2020-04-20 Thread Martin Maechler
> Arni Magnusson > on Mon, 20 Apr 2020 16:50:16 + writes: > Dear Martin, > Thank you for the well-reasoned response. I realized I was rather late to make this suggestion for 4.0.0, changing a somewhat low-level function that can indeed affect packages. > I was just