Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
June 22, 2013 [Issue 10448] New: min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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 [Issue 10448] min and max are not NaN aware | ||||
---|---|---|---|---|
| ||||
Posted in reply to monarchdodra@gmail.com | 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: ------- |
Copyright © 1999-2021 by the D Language Foundation