>> > Doesn't the polymorphic comparison have to be a total order?
>
> 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.  There is some remaining weirdness though (as
one would expect), in that the polymorphic nan is equal to everything
else.  As a strange result, if you create a Set from the polymorphic
compare, you get the following weird result:

# Set.elements (Set.of_list [Some 3.; Some nan]);;
- : float option list = [Some 3.]
# Set.elements (Set.of_list [Some nan; Some 3.]);;
- : float option list = [Some nan]

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?  Maybe
make nan the smallest thing bigger than -infinitiy, or the largest thing
smaller than infinity?  It's not perfect, but it seems better than making
it equal to everything.

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.)  In practice, I rely
on equality holding only when two floating point numbers were derived in
precisely the same way or were copies of each other.  But it does come up
quite a bit.

y

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