>>>>> Michal Burda <michal.burda at centrum.cz>
>>>>> on Mon, 15 Jan 2018 12:04:13 +0100 writes:
> Dear R users, is the following OK?
>> max(NA, NaN)
> [1] NA
>> max(NaN, NA)
> [1] NA
>> pmax(NaN, NA)
> [1] NA
>> pmax(NA, NaN)
> [1] NaN
> ...or is it a bug?
> Documentation says that NA has a higher priority over NaN.
which documentation ??
[That would be quite a bit misleading I think. So, it should be amended ...]
> Best regards, Michal Burda
R's help pages are *THE* reference documentation and they have
(for a long time, I think) had :
?NaN has in its 3rd 'Note:'
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).
Similarly, ?NA contains, in its 'Details':
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). ........
-----
Yes, it is a bit unfortunate that this is platform dependent; if
we wanted to make this entirely consistent (as desired in a
perfect world), I'm almost sure R would become slower because
we'd have to do add some explicit "book keeping" / checking
instead of relying on the underlying C library code.
Note that for these reasons, often NaN and NA should not be
differentiated, and that's reason why using is.na(*) is
typically sufficient and "best" -- it gives TRUE for both NA and NaN.
Martin Maechler
ETH Zurich