Comment author: @dbuenzli

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

Comment author: dawidtoton

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

Comment author: @xavierleroy

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.