>>>>> "TTLAM" == Thaler, Thorn, LAUSANNE, Applied Mathematics
>>>>> <thorn.tha...@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
principle.
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".
Martin
TTLAM> BR Thorn
TTLAM> ______________________________________________
TTLAM> R-devel@r-project.org mailing list
TTLAM> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
