max and pmax of NA and NaN

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

max and pmax of NA and NaN

Michal Burda-2
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.


Best regards, Michal Burda

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: max and pmax of NA and NaN

Martin Maechler
>>>>> Michal Burda <[hidden email]>
>>>>>     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

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: max and pmax of NA and NaN

R help mailing list-2
In reply to this post by Michal Burda-2
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.

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

______________________________________________
[hidden email] 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.
Reply | Threaded
Open this post in threaded view
|

Re: max and pmax of NA and NaN

Peter Dalgaard-2


> On 20 Jan 2018, at 07:53 , Suharto Anggono Suharto Anggono via R-help <[hidden email]> 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
>
> ______________________________________________
> [hidden email] 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: [hidden email]  Priv: [hidden email]

______________________________________________
[hidden email] 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.