www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10448] New: min and max are not NaN aware

reply d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 22 2013