From j@gorecki @ending from wit@edu@pl  Tue Jul  3 11:12:07 2018
From: j@gorecki @ending from wit@edu@pl (Jan Gorecki)
Date: Tue, 3 Jul 2018 11:12:07 +0200
Subject: [Rd] base::mean not consistent about NA/NaN
In-Reply-To: <CANVKczPSN6NRVJkwnq3+=RmCxcgQ5OiZAWDoR4qQmNyUeD-PKQ@mail.gmail.com>
References: <CAOO9MKXXtUm=XJc-Wb7k=1ah5yheP-KMfFS3rQKZc7o6GfQF=w@mail.gmail.com>
 <339fdae8e2a3431c9773b51e2ac93ab9@AM6PR04MB4264.eurprd04.prod.outlook.com>
 <CANVKczPSN6NRVJkwnq3+=RmCxcgQ5OiZAWDoR4qQmNyUeD-PKQ@mail.gmail.com>
Message-ID: <CAOO9MKX+NxqRVL=+9iHg0TQi275PzJ99zUTzp5=kLKve1PAL-g@mail.gmail.com>

Thank you for interesting examples.
I would find useful to document this behavior also in `?mean`, while `+`
operator is also affected, the `sum` function is not.
For mean, NA / NaN could be handled in loop in summary.c. I assume that
performance penalty of fix is the reason why this inconsistency still
exists.
Jan

On Mon, Jul 2, 2018 at 8:28 PM, Barry Rowlingson <
b.rowlingson at lancaster.ac.uk> wrote:

> 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.duncan at 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 at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



[Rd] base::mean not consistent about NA/NaN
Jan Gorecki