And for a starker example of this (documented) inconsistency, arithmetic addition is not commutative:
> NA + NaN [1] NA > NaN + NA [1] NaN On Mon, Jul 2, 2018 at 5:32 PM, Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > On 02/07/2018 11:25 AM, Jan Gorecki wrote: >> Hi, >> base::mean is not consistent in terms of handling NA/NaN. >> Mean should not depend on order of its arguments while currently it is. > > The result of mean() can depend on the order even with regular numbers. > For example, > > > x <- rep(c(1, 10^(-15)), 1000000) > > mean(sort(x)) - 0.5 > [1] 5.551115e-16 > > mean(rev(sort(x))) - 0.5 > [1] 0 > > >> >> mean(c(NA, NaN)) >> #[1] NA >> mean(c(NaN, NA)) >> #[1] NaN >> >> I created issue so in case of no replies here status of it can be looked up >> at: >> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17441 > > The help page for ?NaN says, > > "Computations involving NaN will return NaN or perhaps NA: which of > those two is not guaranteed and may depend on the R platform (since > compilers may re-order computations)." > > And ?NA says, > > "Numerical computations using NA will normally result in NA: a possible > exception is where NaN is also involved, in which case either might > result (which may depend on the R platform). " > > So I doubt if this inconsistency will be fixed. > > Duncan Murdoch > >> >> Best, >> Jan >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel