0004696: min & max yield incorrect results with NaN

Notes
(0004826) dbuenzli (reporter) 2009-01-29 15:05	AFAIK IEEE 754-1985 doesn't specify a behaviour for min/max functions. The recent IEEE 754-2008 [1] introduces minNum and maxNum (see 5.3.1). However when presented with a number and a quiet NaN these functions unconditionnaly return the number. So that would be the opposite of what the reporter proposes. Best, Daniel [1] http://ieeexplore.ieee.org/servlet/opac?punumber=4610933 [^]

(0004827) dawidtoton (reporter) 2009-01-30 15:12	The documentation of Pervasives says simply: "any operation with nan as argument returns nan as result" I thought there is a bug in max & min, because their result depends on order of arguments. For me it is natural to assume that (max a b)=(max b a) if the documentation doesn't say otherwise. However I understand that it is more important to have fast max & min operations than to handle NaNs in a specific way. So I reported this too hastily as a bug, this might be better seen as "documentation request".

(0004883) xleroy (administrator) 2009-03-28 18:12	You expected min x NaN = NaN, but as D. Buenzli mentioned, other folks recommend min x NaN = x. In Caml, there is one additional difficulty, namely that min and max apply to composite data structures as well. So, what should be min (x, NaN) (NaN, y), for example? I don't think a "best" behavior exists in this case, so the current implementation is as good (and as bad) as any other.