Re: math.max/math.min given NaN

[David Manura <dm.lua@...>]

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.