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