]> I've gotten a bunch of replies on this, some pointing out that the proper result could be achieved with various methods for detecting nan's explicitly. This kind of misses my point, which is that this leads to some pretty serious violations of the principle of least surprise. The first is that adding a type annotation to a function can change its semantics: the specialized min function I came up with works substantively differently depending on whether it's known at compile-time that it operates only on floats. The second weirdness is the breaking of (==) => (=), since "nan == nan" evaluates to true and "nan = nan" evaluates to false. These are pretty weird and unpleasant surprises, and now that I've been bitten by them I'm eager to avoid them in the future. Hence my desire for a polymorphic equality function that doesn't change it's behavior when applied to floats. y ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners