http://d.puremagic.com/issues/show_bug.cgi?id=10448
--- Comment #8 from [email protected] 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: -------
