[R] max and pmax of NA and NaN

[peter dalgaard]

> On 20 Jan 2018, at 07:53 , Suharto Anggono Suharto Anggono via R-help <r-help at r-project.org> wrote:
> 
> Extremes.Rd, that documents 'max' and 'pmax', has this in "Details" section, in the paragraph before the last.


> By definition the min/max of a numeric vector containing an NaN is NaN, except that the min/max of any vector containing an NA is NA even if it also contains an NaN.

...but how do you infer that this applies to pmin/pmax? You may want it to, but it specifically talks about the non-parallel min/max.

-pd

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

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com