[R] Why the factor levels returned by cut() are not ordered?

[Prof Brian Ripley]

On Wed, 29 Nov 2006, Petr Pikal wrote:

>
>
> On 29 Nov 2006 at 12:08, Peter Dalgaard wrote:
>
> Date sent:      	Wed, 29 Nov 2006 12:08:21 +0100
> From:           	Peter Dalgaard <P.Dalgaard at biostat.ku.dk>
> To:             	Wolfram Fischer <wolfram at fischer-zim.ch>
> Copies to:      	r-help at stat.math.ethz.ch
> Subject:        	Re: [R] Why the factor levels returned by cut() are not ordered?
>
>> Wolfram Fischer wrote:
>>> What is the reason, that the levels of the factor
>>> returned by cut() are not marked as ordered levels?
>>>
>>>
>>>> is.ordered( cut( breaks=3, sample(10 ) ) )
>>>>
>>> FALSE
>>>
>>>
>> It would arguably be the Right Thing, but there would be complications
>> in modeling, where ordered factors result in polynomial contrast
>> coding. (This, in my opinion, is a design mistake inherited from S,
>> but it's not easy to change at this stage.)
>
> Well
>
> what about to change cut.default
>
> if (codes.only)
>         code
>     else factor(code, seq(labels), labels)
>
> to
>
> if (codes.only)
>         code
>     else factor(code, seq(labels), labels, ...)

Hmm, did you read the help for cut?

      ...: further arguments passed to or from other methods.

and so very likely factor() would barf at some of these. I'll add an 
'ordered' argument to cut.default for R-devel.

>
> which enables to use ordered switch
>
>> is.ordered( cut( breaks=3, sample(10 ), ordered=T ) )
> [1] TRUE
>
> Without this the result is same as before (I believe :-)

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595