[R] prod(NaN, NA) vs. prod(NA, NaN)

Ted Harding ted@h@rd|ng @end|ng |rom w|@ndre@@net
Wed Jul 4 20:18:46 CEST 2018


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 <r.turner using auckland.ac.nz> 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
> >
> > ______________________________________________
> > R-help using r-project.org 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.
> 
> ______________________________________________
> R-help using r-project.org 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.




More information about the R-help mailing list