[Issue 10448] min and max are not NaN aware

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sat Jun 22 15:11:45 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=10448



--- Comment #8 from thelastmammoth at 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: -------


More information about the Digitalmars-d-bugs mailing list