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

[Barry Rowlingson]

On Tue, Jul 3, 2018 at 10:12 AM, Jan Gorecki <j.gorecki using wit.edu.pl> wrote:
> 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.

`sum` is "affected" on my system, if you mean:

> sum(c(NA,NaN))
[1] NA
> sum(c(NaN,NA))
[1] NaN

oh, maybe you mean:

> sum(NaN, NA)
[1] NA
> sum(NA, NaN)
[1] NA

But whatever, no money back guarantee:

     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).

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