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.tur...@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@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@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@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.