This caught my eye way late and only because of the Apple Mail random-scrollbag
bug!
However it is still not fixed in 3.5.0 and as you say, it should be easy.
(Notice that you need to look at the last SO responses, the first 4 are
useless...)
The cause of the trouble seems to be that if decreasing is a vector, you get as
far as
if (method == "radix" || !is.na(na.last))
return(do.call("order",
c(z, na.last = na.last, decreasing = decreasing, method = method)))
and then the c() construct does you in, because of this effect
> c(list(1:10),decreasing=c(TRUE,FALSE))
[[1]]
[1] 1 2 3 4 5 6 7 8 9 10
$decreasing1
[1] TRUE
$decreasing2
[1] FALSE
This should indeed be easily fixable by wrapping the vector or, maybe better,
all arguments other than z in list(). Will fix (in R-devel for now as the
urgency doesn't seem that great).
-pd
> On 14 Sep 2017, at 17:03 , Karl Nordstr?m <karl.nordstroem at
uni-saarland.de> wrote:
>
> Dear R-devel(opers),
>
> I wanted to draw your attention to a small problem with the order function
in base. According to the documentation, radix sort supports different orders
for each argument. This breaks when one of the arguments is an object.
>
> Please have a look to this stackoverflow question:
>
>
https://stackoverflow.com/questions/39737871/r-order-method-on-multiple-columns-gives-error-argument-lengths-differ
>
> It describes the problem well and suggests a solution.
>
> Although it is a niche case, it's a very easy thing to fix :)
>
> Best regards,
>
> Karl Nordstr?m
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com