[Rd] Minimum of an ordered factor

Martin Maechler maechler at stat.math.ethz.ch
Fri Jan 7 11:57:19 CET 2011

>>>>> "TTLAM" == Thaler, Thorn, LAUSANNE, Applied Mathematics <Thorn.Thaler at rdls.nestle.com>
>>>>>     on Thu, 6 Jan 2011 15:37:01 +0100 writes:

    TTLAM> Kurt Hornik writes
    >> >> if (!all(sapply(args, is.ordered)) ||
    >> >> !all(sapply(level.list, identical, y = level.set))) {
    >> I think it would be better to use something like
    >> ll <- lapply(args, levels)
    >> !all(sapply(ll, identical, ll[[1L]]))
    >> [using union() is not quite right]

    TTLAM> Yes definitely. This line is in fact just a relic from a previous idea I
    TTLAM> had.
I have now committed the amended proposal (rev 53925);
thank you for the feedbacks..

    >> The general comment is that if we support this I don't see why we
    >> should
    >> not also support c.ordered (and in fact also c.factor) with the same
    >> restrictions (identical level sequences for ordered and level sets for
    >> factors).  We already have Ops.factor and Ops.ordered using the same
    >> principle afaic.

Yes, I think, too.

    >> If we add c.ordered, we should be able to encapsulate the identity of
    >> levels testing into this, and simply use
    >> x <- c(...)
    >> and then call .Generic on the codes of x etc.

    TTLAM> Sounds reasonable. Ack.

Yes, adding c.factor() and c.ordered() seems reasonable in
However, S and R now have a more than 20 year old history of
silently coercing factors to there integer codes with c(),
that I'm not yet sure we can do this without breaking too much
code [[and I am pretty sure this topic has been discusses before]].

I think we should start discussing the issue in a new thread
with proper Subject explicitly mention "c()" or "c.factor"/"c.ordered".

    TTLAM> BR Thorn

    TTLAM> ______________________________________________
    TTLAM> R-devel at r-project.org mailing list
    TTLAM> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list