I've been following this thread, and wondering where it might lead.

My (possibly naive) view of these matters is basically logical,

relying on (possibly over-simplified) interpretaions of "NA" and "NaN".

These are that:

"NaN" means "Not a Number", though it can result from a

numerical calculation, e.g. '0/0' or 'Inf/Inf', while:

"NA" means "Not Available" (e.g. "Missing Value"), but

should be interpreted as in rhe appropriate class of its

context -- so '2 + NA' interporets "NA" as numeric,

while 'vec("abc",NA)' interprets "NA" as character.

On that basis, the result of 'sum(NaN, <anything>)' should be

"NaN", since 'sum' presumes that its arguments are numeric,

and the sum of <bumbers, not-a-number> is not a number.

Likewise 'sum(<anything>, NaN)' should be NaN.

And in both of 'sum(NA, NaN) and sum(NaN, NA), the "NA" should

be interepreted as a "not-available number", and because

of the "NaN" the result cannot be a number, hence is "NaN".

So it sould seem that Martin Møller Skarbiniks Pedersen's

inconsistency:

sum(c(NaN,NA))

[1] NaN

sum(NaN,NA)

[1] NA

is not consistent with the above reasoning.

However, in my R version 2.14.0 (2011-10-31):

sum(NaN,NA)

[1] NA

sum(NA,NaN)

[1] NA

which **is** consistent! Hmmm...

Best wishes to all,

Ted.

On Wed, 2018-07-04 at 12:06 +0100, Barry Rowlingson wrote:

> I'm having deja-vu of a similar discussion on R-devel:

>

>

https://stat.ethz.ch/pipermail/r-devel/2018-July/076377.html>

> This was the funniest inconsistency I could find:

>

> > sum(c(NaN,NA))

> [1] NaN

> > sum(NaN,NA)

> [1] NA

>

> THEY'RE IN THE SAME ORDER!!!

>

> The doc in ?NaN has this clause:

>

> In R, basically all mathematical functions (including basic

> ‘Arithmetic’), are supposed to work properly with ‘+/- Inf’ and

> ‘NaN’ as input or output.

>

> which doesn't define "properly", but you'd think commutativity was a

> "proper" property of addition. So although they "are supposed to" they

> don't. Naughty mathematical functions!

>

> And then there's...

>

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

>

> Which is at least telling you there is vagueness in the system. But

> hey, mathematics is not a precise science... oh wait...

>

> Barry

>

>

>

>

>

> On Tue, Jul 3, 2018 at 10:09 PM, Rolf Turner <

[hidden email]> wrote:

> >

> > On 04/07/18 00:24, Martin Møller Skarbiniks Pedersen wrote:

> >

> >> Hi,

> >> I am currently using R v3.4.4 and I just discovered this:

> >>

> >>> prod(NA, NaN) ; prod(NaN, NA)

> >> [1] NA

> >> [1] NaN

> >>

> >> ?prod says:

> >> If ‘na.rm’ is ‘FALSE’ an ‘NA’ value in any of the arguments will

> >> cause a value of ‘NA’ to be returned, otherwise ‘NA’ values are

> >> ignored.

> >>

> >> So according to the manual-page for prod() NA should be returned in both

> >> cases?

> >>

> >>

> >> However for sum() is opposite is true:

> >>> sum(NA, NaN) ; sum(NaN, NA)

> >> [1] NA

> >> [1] NA

> >>

> >> ?sum says:

> >> If ‘na.rm’ is ‘FALSE’ an ‘NA’ or ‘NaN’ value in any of the

> >> arguments will cause a value of ‘NA’ or ‘NaN’ to be returned,

> >> otherwise ‘NA’ and ‘NaN’ values are ignored.

> >>

> >>

> >> Maybe the manual for prod() should say the same as sum() that

> >> both NA and NaN can be returned?

> >

> > But:

> >

> > > sum(NA,NaN)

> > [1] NA

> > > sum(NaN,NA)

> > [1] NA

> >

> > so sum gives NA "both ways around". Perhaps a slight inconsistency

> > here? I doubt that it's worth losing any sleep over, however.

> >

> > Interestingly (???):

> >

> > > NaN*NA

> > [1] NaN

> > > NA*NaN

> > [1] NA

> > > NaN+NA

> > [1] NaN

> > > NA+NaN

> > [1] NA

> >

> > So we have an instance of non-commutative arithmetic operations. And

> > sum() is a wee bit inconsistent with "+".

> >

> > Again I doubt that the implications are all that serious.

> >

> > cheers,

> >

> > Rolf Turner

> >

> > --

> > Technical Editor ANZJS

> > Department of Statistics

> > University of Auckland

> > Phone: +64-9-373-7599 ext. 88276

> >

> > ______________________________________________

> >

[hidden email] mailing list -- To UNSUBSCRIBE and more, see

> >

https://stat.ethz.ch/mailman/listinfo/r-help> > PLEASE do read the posting guide

http://www.R-project.org/posting-guide.html> > and provide commented, minimal, self-contained, reproducible code.

>

> ______________________________________________

>

[hidden email] mailing list -- To UNSUBSCRIBE and more, see

>

https://stat.ethz.ch/mailman/listinfo/r-help> PLEASE do read the posting guide

http://www.R-project.org/posting-guide.html> and provide commented, minimal, self-contained, reproducible code.

______________________________________________

[hidden email] mailing list -- To UNSUBSCRIBE and more, see

https://stat.ethz.ch/mailman/listinfo/r-helpPLEASE do read the posting guide

http://www.R-project.org/posting-guide.htmland provide commented, minimal, self-contained, reproducible code.