This has been rehashed several times over the years... One aspect, which is often overlooked is that all factors have orderINGs even when they are not orderED. This controls how you print them, tabulate them, which level is the baseline for treatment contrasts, etc. So you do need a way to access the position in the ordering for a given factor level. (People who blindly convert factors to character may realize that their analyses come out different depending on the collating sequence of the current locale. Or just find that their graphs come out with Month sorted alphabetically.)
A related issue that has bugged me "forever" is that we treat ordered factors as if their levels are equidistant even when that is patently untrue. The use of polynomial contrasts for ordered factors reflects this - it would really be more sensible to use e.g. successive differences or (ick!) Helmert contrasts for the ordered case and reserve poly() for factors with actual numerical levels. To me, this effectively makes ordered factors conceptually useless. - Peter D. > On 24 Oct 2025, at 07.40, Roland Fuß via R-devel <[email protected]> > wrote: > > I think this bug highlights a much more fundamental issue: > > Conceptually, as.numeric should throw an error for unordered factors or > return NaN values or maybe behave like as.numeric(as.character(<factor>)). > Even a warning would be an improvement. I know a change like this is pretty > much impossible but the examples in help("numeric") already acknowledge how > unintuitive current behavior is. I suspect almost everbody teaching R to > beginners covers what as.numeric(<factor>) actually does (cf. The R Inferno, > Section 8.2.1). And that shouldn't be necessary. > > Roland > > Am 22.10.2025 um 11:11 schrieb Martin Maechler: >>>>>>> Roland Fuß via R-devel >>>>>>> on Wed, 22 Oct 2025 10:24:07 +0200 writes: >> > This doesn't seem intended. >> >> You are right. The code change, reverting to previous behaviour >> notably for "Date", >> was prompted on this R-devel list, >> https://stat.ethz.ch/pipermail/r-devel/2022-July/081850.html >> >> But that the change allows poly(<factor>, .) to work was overlooked (by >> me and anyone else ..) and is a bug we will change. >> >> > See: >> >> > >> https://stackoverflow.com/questions/79795583/why-does-poly-work-for-unordered-factors-it-previously-did-not-work >> >> As was already raised in the above SO thread, >> what should happen for *ordered* factors is less obvious. >> A warning was proposed, but I thought that this was too harsh; >> hence, we could use message(), or just keep allowing it. >> >> Opinions? >> >> Martin >> >> -- >> Martin Maechler >> ETH Zurich and R Core team >> >> > -- >> > Dr. Roland Fuß >> >> > Thünen-Institut für Agrarklimaschutz/ >> > Thünen Institute of Climate-Smart Agriculture >> >> > Bundesallee 65 >> > D-38116 Braunschweig, Germany > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business SchoolSolbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: [email protected] Priv: [email protected] ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
