[Rd] bug report: inaccurate error message for stats::chisq.test
Hi,
`stats::chisq.test` checks that x and y each have at least 2 levels AFTER
filtering on complete cases.
It makes sense but the error message is misleading : “'x' and 'y' must have
at least 2 levels”
Here’s how to reproduce the issue :
x <- structure(c(1L, 1L, 1L, 2L, 1L, 2L), .Label = c("0001", "0003"),
class = "factor")
y <- structure(c(1L, 2L, 2L, NA, 2L, NA), .Label = c("0001", "0002"),
class = "factor")
chisq.test(x,y)
# Error in chisq.test(...) : 'x' and 'y' must have at least 2 levels
In this case they do have 2 levels.
Best regards,
Antoine
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] head with non integer n returns confusing output
Dear all, `head()` returns a problematic output when a character is fed to its `n` parameter. doubles and logicals are converted to integer as if `as.integer` was used, which I think is intuitive enough : ``` head(1:10, 4.1) # [1] 1 2 3 4 head(1:10, 4.9) # [1] 1 2 3 4 head(1:10, TRUE) # 1 head(1:10, FALSE) # integer(0) ``` But characters have a stranger behavior : ``` head(1:10, "0") # integer(0) head(1:10, "0.1") # integer(0) head(1:10, "1") # [1] 1 head(1:10, "1.2") # [1] 1 head(1:10, "2") # [1] [1] 1 2 3 4 5 6 7 8 9 10 head(1:10, "-1") # Error in length(x) + n : non-numeric argument to binary operator head(1:10, "-0") # Error in length(x) + n : non-numeric argument to binary operator head(1:10, "foo") # [1] 1 2 3 4 5 6 7 8 9 10 ``` When forgetting to convert user input to numeric this can lead to an unexpected and inconsistent result. I would suggest either using `as.integer` consistently on the input, or having a consistent error for all character input. `n = NA` also a returns a somewhat misleading error as it demands a logical input while the top level function requires an integer input. ``` head(1:10, NA) # same output for head(1:10, NA_integer_) # Error in if (n < 0L) max(length(x) + n, 0L) else min(n, length(x)) : # missing value where TRUE/FALSE needed ``` Kind regards, Antoine [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] install packages with missing pkg argument
Dear all, The help for `?install.packages` decribes, in the `pkg` argument description : > If this is missing, a listbox of available packages is presented where possible in an interactive R session. In fact running it with a missing argument triggers an error : install.packages() > Error in install.packages : argument "pkgs" is missing, with no default What however doesn't trigger an error is callinginstall.packages on a zero length character : install.packages(character(0)) On my colleague's R 3.5.1 windows installation it shows the listbox of available packages, on my 3.6.0 installation it pauses for a couple seconds and doesn't do anything. A character vector of length zero is what you get when you compute an empty `setdiff` or `intersection`, so it was very surprising to us to see something popup where we were expecting a vector of missing packages to be installed (or none if there was no missing package). I believe having the function work as advertised with a proper missing argument, and having it do nothing silently when the argument is of length zero, would make more sense. Best regards, Antoine [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install packages with missing pkg argument
Indeed Hugh, apologies for the oversight, I've reported this to Rstudio, as I believe it is problematic to get an irrelevant help file when calling `?install.packages`. https://github.com/rstudio/rstudio/issues/5154 Best regards, Antoine Le lun. 29 juil. 2019 à 13:59, Hugh Parsonage a écrit : > Are you running that command in RStudio? And do you get the documented > results when you run utils::install.packages() rather than just > install.packages() > > If yes, then the function is likely working as advertised and you've > mixed up the R and RStudio versions > > > On 29/07/2019, Ant F wrote: > > Dear all, > > > > The help for `?install.packages` decribes, in the `pkg` argument > > description : > > > >> If this is missing, a listbox of available packages is presented where > > possible in an interactive R session. > > > > In fact running it with a missing argument triggers an error : > > > > install.packages() > >> Error in install.packages : argument "pkgs" is missing, with no default > > > > What however doesn't trigger an error is callinginstall.packages on a > zero > > length character : > > > > install.packages(character(0)) > > > > On my colleague's R 3.5.1 windows installation it shows the listbox of > > available packages, on my 3.6.0 installation it pauses for a couple > seconds > > and doesn't do anything. > > > > A character vector of length zero is what you get when you compute an > empty > > `setdiff` or `intersection`, so it was very surprising to us to see > > something popup where we were expecting a vector of missing packages to > be > > installed (or none if there was no missing package). > > > > I believe having the function work as advertised with a proper missing > > argument, and having it do nothing silently when the argument is of > length > > zero, would make more sense. > > > > Best regards, > > > > Antoine > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install packages with missing pkg argument
Indeed it's a RStudio issue as diagnosed by Hugh, and is still an issue with the latest version. Le lun. 29 juil. 2019 à 15:02, Duncan Murdoch a écrit : > On 29/07/2019 7:39 a.m., Ant F wrote: > > Dear all, > > > > The help for `?install.packages` decribes, in the `pkg` argument > > description : > > > >> If this is missing, a listbox of available packages is presented where > > possible in an interactive R session. > > > > In fact running it with a missing argument triggers an error : > > > > install.packages() > >> Error in install.packages : argument "pkgs" is missing, with no default > > > > What however doesn't trigger an error is callinginstall.packages on a > zero > > length character : > > > > install.packages(character(0)) > > > > On my colleague's R 3.5.1 windows installation it shows the listbox of > > available packages, on my 3.6.0 installation it pauses for a couple > seconds > > and doesn't do anything. > > > > A character vector of length zero is what you get when you compute an > empty > > `setdiff` or `intersection`, so it was very surprising to us to see > > something popup where we were expecting a vector of missing packages to > be > > installed (or none if there was no missing package). > > > > I believe having the function work as advertised with a proper missing > > argument, and having it do nothing silently when the argument is of > length > > zero, would make more sense. > > > > The change you are requesting is listed as having been done in the NEWS > for 3.6.0... > > Duncan Murdoch > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fwd: Document colon equals `:=` operator ?
Dear all, There was some discussion lately on twitter ( https://twitter.com/geospacedman/status/1164208293377691648 ) about the status of the colon equal operator. I'm sure it has been discussed in the past but I couldn't find anything, I'll start by clarifying all i can by myself to have strong reference, and then ask a few questions at the bottom. `:=` has been used by data table for a very long time and more recently by tidyverse packages through rlang package, in both cases to parse expressions (it's also defined and exported by data.table but just to trigger an error). It was used in ggvis too, and I have myself designed the package dotdot that defines it. I'm note aware of other uses in packages though it pops up from time to time in Stack Overflow 's Q&A. It has the same precedence as `<-`. It is used by data.table and tidyverse to provide key / value pairs to function arguments where `=` would trigger a failure. It can also convenient at the top level because the rhs is NOT evaluated/copied before entering the function, as it is with `=` and `<-`. My understanding based on : * John Chambers 2001 : https://developer.r-project.org/equalAssign.html * Matt Dowle 2011 : https://stackoverflow.com/questions/7033106/why-has-data-table-defined-rather-than-overloading is that `:=` used to be an equivalent to `<-`, along with `_`. At some point the decision was made to remove `_` and `:=`. BUT, and as I understand it started as a mistake, the `:=` operator was kept (without definition). Then Matt Dowle used it in data.table, which gained tremendous popularity, and thus it was kept around, and later implemented by Hadley Wickham and Lionel Henry in rlang as a central component of tidy evaluation. ?data.table::`:=` and ?rlang::`:=` describe how to use the operator in the context of the package but don't refer to its undocumented status. Some relevant chunks of source code : * https://github.com/wch/r-source/blob/tags/R-3-6-1/src/main/gram.y#L379-L381 * https://github.com/wch/r-source/blob/tags/R-3-6-1/src/main/gram.y#L2999-L3002 Now for the questions : Some R users worry that the use of `:=` is not safe, as it is undocumented. It would be good to be able for package authors to reassure their users that the package won't break because R Core decides to remove the operator at some point, or change its behavior. * Could we have an official statement that the `:=` operator is NOT going to be removed and can be used safely in packages ? OR could we have an official statement that the use of the `:=` is discouraged and unsafe given it might be removed at some point * If we can have confirmation that the operator won't be removed (and thus can be used for parsing), could we also have an official statement that it will also remain possible to define it ? (which data.table and tidyverse don't require for instance, but dotdot does) OR have a statement that assuming this is not safe. * Could we have these statements reflected in the doc ? Or why can't we ? I believe that even if R Core discourages the use of `:=`, this should be reflected in the doc. Users encountering it should still be able to understand what's going on through the base documentation. Referencing it in `?Syntax` along with a short note would go a long way. Many thanks and apologies for the possible redundancy with previous threads, Antoine [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] ?Syntax wrong about `?`'s precedence ?
Dear all,
`?Syntax` documents that `?` has the lowest precedence, right under `=`.
Indeed it reads:
*The following unary and binary operators are defined. They are listed in
precedence groups, from highest to lowest. *
and ends the list with
*<- <<-* *assignment (right to left)*
*=* *assignment (right to left)*
*?* *help (unary and binary)*
I believe it to be wrong, `=` has lower precedence than `?`.
See the following example :
`?` <- `+`
x = 2 ? 3
x
#> [1] 5
We see that `2 ? 3` is evaluated first, then the result is assigned to x,
showing
higher precedence for `?`.
Compare it to the similar code using `<-` :
x <- 2 ? 3
#> [1] 5
x
#> [1] 2
Here first `x <- 2` is evaluated, then its output is added to 3, and the
result
`5` is printed. and we verify that `x` is still `2`. Showing lower
precedence
for `?` consistent with the doc.
Hadley Wickham's package `lobstr` makes it easy to compare the parse trees:
lobstr::ast({x = 2 ? 3})
#> o-`{`
#> \-o-`=`
#> +-x
#> \-o-`?`
#> +-2
#> \-3
lobstr::ast({x <- 2 ? 3})
#> o-`{`
#> \-o-`?`
#> +-o-`<-`
#> | +-x
#> | \-2
#> \-3
Best regards,
Antoine
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rbind returns a zero row data frame when binding zero column data frames
Dear all, `rbind()` returns a zero row data frame when binding zero column data frames, see example below: ``` r # a data frame with 1 row and 0 column x <- data.frame(row.names=1) x #> data frame with 0 columns and 1 row rbind(x,x) #> data frame with 0 columns and 0 rows ``` I would have expected in that case `data frame with 0 columns and 2 rows`. `cbind()` on the other hand acts as I would expect, returning a 2 column data frame from 2 one column data frames even if they have no row. ``` r # a data frame with 0 row and 1 column y <- data.frame(A = numeric(0)) y #> [1] A #> <0 rows> (or 0-length row.names) cbind(y,y) #> [1] A A #> <0 rows> (or 0-length row.names) ``` [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] should base R have a piping operator ?
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
their code or doc and stay dependency free.
I don't suggest an operator based on complex heuristics, instead I suggest
a very simple and fast one (>10 times than magrittr in my tests) :
`%.%` <- function (e1, e2) {
eval(substitute(e2), envir = list(. = e1), enclos = parent.frame())
}
iris %.% head(.) %.% dim(.)
#> [1] 6 5
The difference with magrittr is that the dots must all be explicit (which
sits with the choice of the name), and that special magrittr features such
as assignment in place and building functions with `. %>% head() %>% dim()`
are not supported.
Edge cases are not surprising:
```
x <- "a"
x %.% quote(.)
#> .
x %.% substitute(.)
#> [1] "a"
f1 <- function(y) function() eval(quote(y))
f2 <- x %.% f1(.)
f2()
#> [1] "a"
```
Looking forward for your thoughts on this,
Antoine
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should base R have a piping operator ?
Hi John,
Thanks, but the Bizzaro pipe comes with many flaws though :
* It's not a single operator
* It has a different precedence
* It cannot be used in a subcall
* The variable assigned to must be on the right
* It doesn't trigger indentation when going to the line
* It creates/overwrite a `.` variable in the worksace.
And it doesn't deal gracefully with some lazy evaluation edge cases such as
:
compose <- function(f, g) { function(x) g(f(x)) }
plus1 <- function(x) x + 1
plus2 <- plus1 %.% compose(.,plus1)
plus2(5)
#> [1] 7
plus1 ->.; compose(.,plus1) -> .; . -> 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 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-doppelganger/ ), and for
> some reason we chickened out and didn't spend time on it in the dot pipe
> paper ( https://journal.r-project.org/archive/2018/RJ-2018-042/index.html
> ).
>
> For documentation Bizarro pipe has the advantage that one can work out how
> it works from the application itself, with out reference to a defining
> function.
>
> On Oct 5, 2019, at 7:34 AM, Ant F wrote:
>
> 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
> their code or doc and stay dependency free.
>
> I don't suggest an operator based on complex heuristics, instead I suggest
> a very simple and fast one (>10 times than magrittr in my tests) :
>
> `%.%` <- function (e1, e2) {
> eval(substitute(e2), envir = list(. = e1), enclos = parent.frame())
> }
>
> iris %.% head(.) %.% dim(.)
> #> [1] 6 5
>
> The difference with magrittr is that the dots must all be explicit (which
> sits with the choice of the name), and that special magrittr features such
> as assignment in place and building functions with `. %>% head() %>% dim()`
> are not supported.
>
> Edge cases are not surprising:
>
> ```
> x <- "a"
> x %.% quote(.)
> #> .
> x %.% substitute(.)
> #> [1] "a"
>
> f1 <- function(y) function() eval(quote(y))
> f2 <- x %.% f1(.)
> f2()
> #> [1] "a"
> ```
>
> Looking forward for your thoughts on this,
>
> Antoine
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
> ---
> John Mount
> http://www.win-vector.com/
> Our book: Practical Data Science with R
> https://www.manning.com/books/practical-data-science-with-r-second-edition
> <http://www.manning.com/zumel/>
>
>
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should base R have a piping operator ?
Hi Rui,
> R is a functional language, pipes are not. There are even higher order
functions such as [1] and [2].
If they can be build in R, either R is not a functional language, or pipes
are part of a functional language. Could you elaborate ?
What point would you make against pipes that you couldn't make about other
operators or functions leveraging lazy evaluation ?
I don't understand either the references to Negate() and Recall().
I actually think that there are few things more "functional" than using
pipes :).
> Besides, packages are part of R, R couldn't live without them. I find
> pipes a good idea but I also find it better not to have them as part of
> base R. If you want to use them, load a package, if you don't, don't.
> This simple.
Simple enough, but more complicated than necessary.
I believe it's a fair argument to point than pipes are different. They
don't DO anything and yet are used by thousands of packages.
They are largely viewed as part of R and some users are surprised no to
find them in base R, in the remaining users many don't
even know that they come from magrittr but think they come from dplyr.
The fact that it feels odd to attach a package only to use the pipe is
highlighted by the fact that thousands of packages reexport it
, see https://github.com/search?q=filename%3Autils-pipe.R+magrittr . I
don't think it can be said of any other function.
Package developers could still use `usethis::use_pipe()` if they want to
associate their package
with magrittr's pipe, but they wouldn't "need" it to suggest to user than
piping is recommend way of using their functions in sequence,
and this would mean less red ink saying that this `%>%` pipe was masked by
that other `%>%` pipe.
I like the design of magrittr's pipe a lot and I'd continue to use it
either way, but I would write documentation and even functions with `%.%`
if it was available,
without worrying about dependencies, and less worried about suboptimal
performance.
Best regards,
Antoine
Le sam. 5 oct. 2019 à 18:03, Rui Barradas a écrit :
> Hello,
>
> R is a functional language, pipes are not. There are even higher order
> functions such as [1] and [2].
> Besides, packages are part of R, R couldn't live without them. I find
> pipes a good idea but I also find it better not to have them as part of
> base R. If you want to use them, load a package, if you don't, don't.
> This simple.
>
> As for your example, compose, there is a StackOverflow question on it.
> See this answer [3].
>
> [1] https://stat.ethz.ch/R-manual/R-devel/library/base/html/funprog.html
> [2] https://stat.ethz.ch/R-manual/R-devel/library/base/html/Recall.html
> [3] https://stackoverflow.com/a/52465956/8245406
>
> Hope this helps,
>
> Rui Barradas
>
> Às 16:48 de 05/10/19, Ant F escreveu:
> > Hi John,
> >
> > Thanks, but the Bizzaro pipe comes with many flaws though :
> > * It's not a single operator
> > * It has a different precedence
> > * It cannot be used in a subcall
> > * The variable assigned to must be on the right
> > * It doesn't trigger indentation when going to the line
> > * It creates/overwrite a `.` variable in the worksace.
> >
> > And it doesn't deal gracefully with some lazy evaluation edge cases such
> as
> > :
> >
> > compose <- function(f, g) { function(x) g(f(x)) }
> > plus1 <- function(x) x + 1
> >
> > plus2 <- plus1 %.% compose(.,plus1)
> > plus2(5)
> > #> [1] 7
> >
> > plus1 ->.; compose(.,plus1) -> .; . -> 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 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-doppelganger/ ), and
> for
> >> some reason we chickened out and didn't spend time on it in the dot pipe
> >> paper (
> https://journal.r-project.org/archive/2018/RJ-2018-042/index.html
> >> ).
> >>
> >> For documentation Bizarro pipe has the advantage that one can work out
> how
> >> it works from the application itself, with out reference to a
Re: [Rd] should base R have a piping operator ?
Yes but this exageration precisely misses the point. Concerning your examples: * I love fread but I think it makes a lot of subjective choices that are best associated with a package. I think it changed a lot with time and can still change, and we have great developers willing to maintain it and be reactive regarding feature requests or bug reports *.group_by() adds a class that works only (or mostly) with tidyverse verbs, that's very easy to dismiss it as an inclusion in base R. * summarize is an alternative to aggregate, that would be very confusing to have both Now to be fair to your argument we could think of other functions such as data.table::rleid() which I believe base R misses deeply, and there is nothing wrong with packaged functions making their way to base R. Maybe there's an existing list of criteria for inclusion, in base R but if not I can make one up for the sake of this discussion :) : * 1) the functionality should not already exist * 2) the function should be general enough * 3) the function should have a large amount of potential of users * 4) the function should be robust, and not require extensive maintenance * 5) the function should be stable, we shouldn't expect new features ever 2 months * 6) the function should have an intuitive interface in the context of the rest ot base R I guess 1 and 6 could be held against my proposal, because : (1) everything can be done without pipes (6) They are somewhat surprising (though with explicit dots not that much, and not more surprising than say `bquote()`) In my opinion the + offset the -. I wouldn't advise taking magrittr's pipe (providing the license allows so) for instance, because it makes a lot of design choices and has a complex behavior, what I propose is 2 lines of code very unlikely to evolve or require maintenance. Antoine PS: I just receive the digest once a day so If you don't "reply all" I can only react later. Le sam. 5 oct. 2019 à 19:54, Hugh Marera a écrit : > I exaggerated the comparison for effect. However, it is not very difficult > to find functions in dplyr or data.table or indeed other packages that one > may wish to be in base R. Examples, for me, could include > data.table::fread, dplyr::group_by & dplyr::summari[sZ]e combo, etc. Also, > the "popularity" of magrittr::`%>%` is mostly attributable to the tidyverse > (an advanced superset of R). Many R users don't even know that they are > installing the magrittr package. > > On Sat, Oct 5, 2019 at 6:30 PM Iñaki Ucar wrote: > >> On Sat, 5 Oct 2019 at 17:15, Hugh Marera wrote: >> > >> > How is your argument different to, say, "Should dplyr or data.table be >> > part of base R as they are the most popular data science packages and >> they >> > are used by a large number of users?" >> >> Two packages with many features, dozens of functions and under heavy >> development to fix bugs, add new features and improve performance, vs. >> a single operator with a limited and well-defined functionality, and a >> reference implementation that hasn't changed in years (but certainly >> hackish in a way that probably could only be improved from R itself). >> >> Can't you really spot the difference? >> >> Iñaki >> > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] should base R have a piping operator ?
> > > > expression(5 -> x) > > > >> expr[[1]] > > > > x <- 5 > > > > > > Though thats a much more minor transformation. > > > > All of that said, I believe Jim Hester (cc'ed) suggested something along > > these lines at the RSummit a couple of years ago, and thus far R-core has > > not shown much appetite for changing things in the parser. > > > > Without that changing, I'd have to say that my vote, for whatever its > > worth, comes down on the side of pipes being fine in packages. A summary > of > > my reasoning being that it only makes sense for them to go into R itself > if > > doing so fixes an issue that cna't be fixed with them in package space. > > > > Best, > > ~G > > > > > > > > On Sun, Oct 6, 2019 at 5:26 AM Ant F wrote: > > > >> Yes but this exageration precisely misses the point. > >> > >> Concerning your examples: > >> > >> * I love fread but I think it makes a lot of subjective choices that are > >> best associated with a package. I think it > >> changed a lot with time and can still change, and we have great > developers > >> willing to maintain it and be reactive > >> regarding feature requests or bug reports > >> > >> *.group_by() adds a class that works only (or mostly) with tidyverse > verbs, > >> that's very easy to dismiss it as an inclusion in base R. > >> > >> * summarize is an alternative to aggregate, that would be very > confusing to > >> have both > >> > >> Now to be fair to your argument we could think of other functions such > as > >> data.table::rleid() which I believe base R misses deeply, > >> and there is nothing wrong with packaged functions making their way to > base > >> R. > >> > >> Maybe there's an existing list of criteria for inclusion, in base R but > if > >> not I can make one up for the sake of this discussion :) : > >> * 1) the functionality should not already exist > >> * 2) the function should be general enough > >> * 3) the function should have a large amount of potential of users > >> * 4) the function should be robust, and not require extensive > maintenance > >> * 5) the function should be stable, we shouldn't expect new features > ever 2 > >> months > >> * 6) the function should have an intuitive interface in the context of > the > >> rest ot base R > >> > >> I guess 1 and 6 could be held against my proposal, because : > >> (1) everything can be done without pipes > >> (6) They are somewhat surprising (though with explicit dots not that > much, > >> and not more surprising than say `bquote()`) > >> > >> In my opinion the + offset the -. > >> > >> I wouldn't advise taking magrittr's pipe (providing the license allows > so) > >> for instance, because it makes a lot of design choices and has a complex > >> behavior, what I propose is 2 lines of code very unlikely to evolve or > >> require maintenance. > >> > >> Antoine > >> > >> PS: I just receive the digest once a day so If you don't "reply all" I > can > >> only react later. > >> > >> Le sam. 5 oct. 2019 à 19:54, Hugh Marera a > écrit : > >> > >>> I exaggerated the comparison for effect. However, it is not very > >> difficult > >>> to find functions in dplyr or data.table or indeed other packages that > >> one > >>> may wish to be in base R. Examples, for me, could include > >>> data.table::fread, dplyr::group_by & dplyr::summari[sZ]e combo, etc. > >> Also, > >>> the "popularity" of magrittr::`%>%` is mostly attributable to the > >> tidyverse > >>> (an advanced superset of R). Many R users don't even know that they are > >>> installing the magrittr package. > >>> > >>> On Sat, Oct 5, 2019 at 6:30 PM Iñaki Ucar > >> wrote: > >>> > >>>> On Sat, 5 Oct 2019 at 17:15, Hugh Marera > wrote: > >>>>> > >>>>> How is your argument different to, say, "Should dplyr or data.table > >> be > >>>>> part of base R as they are the most popular data science packages and > >>>> they > >>>>> are used by a large number of users?" > >>>> > >>>> Two packages with many features, dozens of functions and under heavy > >>>> development to fix bugs, add new features and improve performance, vs. > >>>> a single operator with a limited and well-defined functionality, and a > >>>> reference implementation that hasn't changed in years (but certainly > >>>> hackish in a way that probably could only be improved from R itself). > >>>> > >>>> Can't you really spot the difference? > >>>> > >>>> Iñaki > >>>> > >>> > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > [[alternative HTML version deleted]] > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
