Thread overview
[Issue 10448] New: min and max are not NaN aware
Jun 22, 2013
Simen Kjaeraas
Jun 22, 2013
Andrej Mitrovic
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448

           Summary: min and max are not NaN aware
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: monarchdodra@gmail.com


--- Comment #0 from monarchdodra@gmail.com 2013-06-22 12:48:40 PDT ---
(and so are probably minCount, minPos, or mostly everything else that is
related to opCmp).

From the discussion https://github.com/D-Programming-Language/phobos/pull/1360
:
min(0, float.nan); //Yields 0
max(0, float.nan); //Yields 0
min(float.nan, 0); //Yields float.nan
max(float.nan, 0); //Yields float.nan

Not sure what the correct solution is: Throwing an exception on NaN might be too expensive? How about an assert, combined with an explicit: "Passing nan is an ERROR", and let the user decide if/ifnot to pay for the check?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448


thelastmammoth@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thelastmammoth@gmail.com


--- Comment #1 from thelastmammoth@gmail.com 2013-06-22 13:13:06 PDT ---
(In reply to comment #0)
> (and so are probably minCount, minPos, or mostly everything else that is
> related to opCmp).
> 
> From the discussion https://github.com/D-Programming-Language/phobos/pull/1360
> :
> min(0, float.nan); //Yields 0
> max(0, float.nan); //Yields 0
> min(float.nan, 0); //Yields float.nan
> max(float.nan, 0); //Yields float.nan
> 
> Not sure what the correct solution is: Throwing an exception on NaN might be too expensive? How about an assert, combined with an explicit: "Passing nan is an ERROR", and let the user decide if/ifnot to pay for the check?

I don't see why one would throw on nan, and it would be expensive.
I believe the accepted convention is that nan is treated as missing data for
min/max, so that
min(0, float.nan); //Yields 0
max(0, float.nan); //Yields 0
min(float.nan, 0); //Yields 0
max(float.nan, 0); //Yields 0

related discussion: http://bytes.com/topic/c/answers/528404-max-nan-0-should-nan matlab does it that way btw.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448


Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simen.kjaras@gmail.com


--- Comment #2 from Simen Kjaeraas <simen.kjaras@gmail.com> 2013-06-22 13:16:30 PDT ---
Exactly. See documentation of fmax at http://man7.org/linux/man-pages/man3/fmax.3.html

Specifically:
       If one argument is a NaN, the other argument is returned.

       If both arguments are NaN, a NaN is returned.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #3 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-06-22 13:31:19 PDT ---
Then it needs to be documented in Phobos, and this fixed:

min(0, float.nan); //Yields 0
min(float.nan, 0); //Yields float.nan (should be 0 then?)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #4 from bearophile_hugs@eml.cc 2013-06-22 13:39:58 PDT ---
(In reply to comment #2)
> Exactly. See documentation of fmax at http://man7.org/linux/man-pages/man3/fmax.3.html
> 
> Specifically:
>        If one argument is a NaN, the other argument is returned.
> 
>        If both arguments are NaN, a NaN is returned.

Isn't it better for min(0, float.nan) to be NaN, just as max(0, float.nan) ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448



--- Comment #5 from monarchdodra@gmail.com 2013-06-22 14:47:00 PDT ---
(In reply to comment #4)
> (In reply to comment #2)
> > Exactly. See documentation of fmax at http://man7.org/linux/man-pages/man3/fmax.3.html
> > 
> > Specifically:
> >        If one argument is a NaN, the other argument is returned.
> > 
> >        If both arguments are NaN, a NaN is returned.
> 
> Isn't it better for min(0, float.nan) to be NaN, just as max(0, float.nan) ?

Yeah, that sounds like the better behavior: *anything* and nan is always nan.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448



--- Comment #6 from thelastmammoth@gmail.com 2013-06-22 14:49:52 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > Exactly. See documentation of fmax at http://man7.org/linux/man-pages/man3/fmax.3.html
> > > 
> > > Specifically:
> > >        If one argument is a NaN, the other argument is returned.
> > > 
> > >        If both arguments are NaN, a NaN is returned.
> > 
> > Isn't it better for min(0, float.nan) to be NaN, just as max(0, float.nan) ?
> 
> Yeah, that sounds like the better behavior: *anything* and nan is always nan.

that would indeed seem more logical, although:

* it differs from standard practice
* it incurs additional cost, compared to : return a<b?a:b; because you'd have
to check for isNan

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448



--- Comment #7 from monarchdodra@gmail.com 2013-06-22 14:59:55 PDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #2)
> > > > Exactly. See documentation of fmax at http://man7.org/linux/man-pages/man3/fmax.3.html
> > > > 
> > > > Specifically:
> > > >        If one argument is a NaN, the other argument is returned.
> > > > 
> > > >        If both arguments are NaN, a NaN is returned.
> > > 
> > > Isn't it better for min(0, float.nan) to be NaN, just as max(0, float.nan) ?
> > 
> > Yeah, that sounds like the better behavior: *anything* and nan is always nan.
> 
> that would indeed seem more logical, although:
> 
> * it differs from standard practice
> * it incurs additional cost, compared to : return a<b?a:b; because you'd have
> to check for isNan

"return a<b?a:b;" doesn't work: you'd have to check for nan regardless of which you return.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
June 22, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10448



--- Comment #8 from thelastmammoth@gmail.com 2013-06-22 15:11:43 PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > > > (In reply to comment #2)
> > > > > Exactly. See documentation of fmax at http://man7.org/linux/man-pages/man3/fmax.3.html
> > > > > 
> > > > > Specifically:
> > > > >        If one argument is a NaN, the other argument is returned.
> > > > > 
> > > > >        If both arguments are NaN, a NaN is returned.
> > > > 
> > > > Isn't it better for min(0, float.nan) to be NaN, just as max(0, float.nan) ?
> > > 
> > > Yeah, that sounds like the better behavior: *anything* and nan is always nan.
> > 
> > that would indeed seem more logical, although:
> > 
> > * it differs from standard practice
> > * it incurs additional cost, compared to : return a<b?a:b; because you'd have
> > to check for isNan
> 
> "return a<b?a:b;" doesn't work: you'd have to check for nan regardless of which you return.

my bad, which is probably why the current min is buggy.
In that case since there's no penalty might as well do the safest thing, ie
returning nan, and provide a minIgnoresNan to do the 'standard behavior', which
will return 0 instead of nan.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------