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