  lua-l archive

• 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.