> > Pervasive.compare must be a total order, so it would need to throw an
> > exception if its arguments are unordered (e.g. one is "nan").
> > The other comparisons (=, <, etc) could implement a partial order,
> > returning "false" in the "unordered" case (except for <>, which should
> > return "true" in this case).
> 
> OK, so this makes me feel a little better -- turns out the polymorphic
> compare is a total order.

I should have been clearer: "would need to..." implies that the
current implementation doesn't do this; only the alternate
implementations that I suggested in a previous message could (and
should) behave this way.

> There is some remaining weirdness though (as
> one would expect), in that the polymorphic nan is equal to everything
> else.

Again, it's a problem (the problem?) with the current implementation,
and it needs fixing.

> I suppose it's too late to change this kind of behavior, but wouldn't it
> make more sense for nan to be different from everything but itself?

Yes, that would be much better.  According to IEEE, nan should even be
different from itself...

> Maybe make nan the smallest thing bigger than -infinitiy, or the
> largest thing smaller than infinity?

This isn't what IEEE does.

> By the way, in my context, there are plenty of times where it makes sense
> to have sets and maps of things that contain floating point numbers
> (although rarely of floating point numbers proper.)  

I'd be interested in some examples, but we can continue this
discussion off the list.

- Xavier Leroy

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