From b@rowling@on @ending from l@nc@@ter@@c@uk  Tue Jul  3 12:12:35 2018
From: b@rowling@on @ending from l@nc@@ter@@c@uk (Barry Rowlingson)
Date: Tue, 3 Jul 2018 11:12:35 +0100
Subject: [Rd] base::mean not consistent about NA/NaN
In-Reply-To: <0035dc229d8c4bdfb7975b4a9975c398@AM6PR04MB4264.eurprd04.prod.outlook.com>
References: <CAOO9MKXXtUm=XJc-Wb7k=1ah5yheP-KMfFS3rQKZc7o6GfQF=w@mail.gmail.com>
 <339fdae8e2a3431c9773b51e2ac93ab9@AM6PR04MB4264.eurprd04.prod.outlook.com>
 <CANVKczPSN6NRVJkwnq3+=RmCxcgQ5OiZAWDoR4qQmNyUeD-PKQ@mail.gmail.com>
 <0035dc229d8c4bdfb7975b4a9975c398@AM6PR04MB4264.eurprd04.prod.outlook.com>
Message-ID: <CANVKczPDibVW_i119aOHkqcR1Ar+ppMaaoRkOz9w-VkV8ZnTNw@mail.gmail.com>

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



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