R help - Nov 2013 - order() function, decreasing=TRUE unexpected behaviour

There appears to be an issue with the decreasing=TRUE option on the order()
function that indicates either a bug or perhaps a design flaw (potentially
flawed because I would suggest the majority of users would expect different
behaviour).

# demonstration of problem:
x <- c(2,1,3,4,5)
order(x)
order(x, decreasing=TRUE)

order(x) correctly reports the order as:
2 1 3 4 5
I expected the result for order(x, decreasing=TRUE) to be:
4 5 3 2 1
but the values actually reported are:
5 4 3 1 2
which is also the result of order(-x) (this may indicate a possible cause of
this issue?).

Thus, the decreasing=TRUE option in the order() function does not reverse the
order of the values reported under the default of decreasing=FALSE in an example
with no ties. If this behaviour is by design I am struggling to understand what
purpose the decreasing=TRUE option serves and would like to suggest that this is
not consistent with how many (most?) users would expect this option to work.

Tested on R2.15.3 and 3.0.1 (both x86_64 linux-gnu) with identical results. I
have also tried it on other series of numbers with the same result.

Apologies if this has been discussed or reported elsewhere but I could not find
any relevant posts. Perhaps I have failed to understand some fundamental issue?
Sorry if this is me being dimwitted - it does seem hard to believe that there is
a bug in a relatively straightforward r-base function. But I thought I would
mention this as it could impact many people.

Many thanks to all the R developers and R community for producing and supporting
such an outstanding and invaluable product.
Hawthorne Beyer
University of Queensland


	[[alternative HTML version deleted]]

I think you are confused, and there is no problem with the order function. Keep
in mind that order returns the index values in a sequence such that when the
result of the order function is used as indexes for the original sequence then
the data will be sorted as desired. You may see the error of your ways more
clearly if you use a vector of strings like
c("b","a","c","d","e") instead
of integer values.

Please configure your email client to send plain text to this list as the
Posting Guide requests, as HTML messes up R code.
---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live
Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
--------------------------------------------------------------------------- 
Sent from my phone. Please excuse my brevity.

Hawthorne Beyer <h.beyer at uq.edu.au> wrote:
>There appears to be an issue with the decreasing=TRUE option on the
>order() function that indicates either a bug or perhaps a design flaw
>(potentially flawed because I would suggest the majority of users would
>expect different behaviour).
>
># demonstration of problem:
>x <- c(2,1,3,4,5)
>order(x)
>order(x, decreasing=TRUE)
>
>order(x) correctly reports the order as:
>2 1 3 4 5
>I expected the result for order(x, decreasing=TRUE) to be:
>4 5 3 2 1
>but the values actually reported are:
>5 4 3 1 2
>which is also the result of order(-x) (this may indicate a possible
>cause of this issue?).
>
>Thus, the decreasing=TRUE option in the order() function does not
>reverse the order of the values reported under the default of
>decreasing=FALSE in an example with no ties. If this behaviour is by
>design I am struggling to understand what purpose the decreasing=TRUE
>option serves and would like to suggest that this is not consistent
>with how many (most?) users would expect this option to work.
>
>Tested on R2.15.3 and 3.0.1 (both x86_64 linux-gnu) with identical
>results. I have also tried it on other series of numbers with the same
>result.
>
>Apologies if this has been discussed or reported elsewhere but I could
>not find any relevant posts. Perhaps I have failed to understand some
>fundamental issue? Sorry if this is me being dimwitted - it does seem
>hard to believe that there is a bug in a relatively straightforward
>r-base function. But I thought I would mention this as it could impact
>many people.
>
>Many thanks to all the R developers and R community for producing and
>supporting such an outstanding and invaluable product.
>Hawthorne Beyer
>University of Queensland
>
>
>	[[alternative HTML version deleted]]
>
>______________________________________________
>R-help at r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide
>http://www.R-project.org/posting-guide.html
>and provide commented, minimal, self-contained, reproducible code.