[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
**Subject**: **Re: math.max/math.min given NaN**
**From**: David Manura <dm.lua@...>
**Date**: Wed, 27 Feb 2008 02:20:21 +0000 (UTC)

Roberto Ierusalimschy writes:
> > > =math.max(1,0/0),math.min(1,0/0)
> > 1 1
> >
> > Is that behavior defined? Should it be defined?
>
> I don't see how to define it unless there is a specific rule for nan.
> Both "x such that x >= y[i]" or "x such that (not y[i] > x)" seem
> undefined when nan is present.
One might do this (not that I'm recommending it):
$ diff -u lmathlib.c~ lmathlib.c
--- lmathlib.c~ 2007-12-27 08:02:25.000000000 -0500
+++ lmathlib.c 2008-02-26 20:06:37.125000000 -0500
@@ -158,6 +158,9 @@
lua_Number d = luaL_checknumber(L, i);
if (d < dmin)
dmin = d;
+ else if (d != d) { /* NaN */
+ dmin = d; break;
+ }
}
lua_pushnumber(L, dmin);
return 1;
@@ -172,6 +175,9 @@
lua_Number d = luaL_checknumber(L, i);
if (d > dmax)
dmax = d;
+ else if (d != d) { /* NaN */
+ dmax = d; break;
+ }
}
lua_pushnumber(L, dmax);
return 1;
But I now see this: "In the IEEE floating-point standard, arithmetic operations
involving NaN always produce NaN....In the proposed IEEE 754r revision of that
standard the same rule applies, except that a few anomalous functions (such as
the maxnum function, which returns the maximum of two operands which are
expected to be numbers) favour numbers—if just one of the operands is a NaN then
the value of the other operand is returned." -- http://en.wikipedia.org/wiki/NaN
Mike Pall writes:
> Few programs rely on perfect NaN propagation. This takes extra
> care and mandates hand-crafted conditionals, anyway. IMHO a small
> remark in the manual would suffice.
This was seen with code that had a logic error causing a NaN, but the
propagation of that NaN wasn't being detected, so that wasn't a case where
perfect NaN propagation was required.