Re: [Caml-list] Weird behavior with nan's and min/max

[Xavier Leroy <xavier.leroy@inria.fr>]

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

> This kind of wigs me out too.  For example, do the set and map data
> structures depend on this total order property?  What happens when I
> stick in a data structure which contains some floats somewhere in it,
> and some of those floats are nan's?  Does the data structure continue to
> work at all?  It totally wigs me out.

Sets and maps require a total order, so, yes, in the current
implementation, strange things can happen with "nan" used as set
elements or map keys.  Again, throwing an "unordered" exception in
Pervasives.compare would avoid the problem.  

Note, however, that it doesn't make much sense to use floats as set
elements or map keys, due to the inherently approximate nature of floats.
E.g. does the set {1.0; 1.0+.epsilon} have 1 or 2 elements?

> I wish there was some sensible way around it.  Probably the thing I
> would like best is for calculations that produce nans to throw
> exceptions.  But from what I've heard so far, this doesn't appear to be
> possible.

The IEEE standard specifies both behaviors: return nan or cause a
floating-point trap, and says that there should be an API to choose
the desired behavior.  Most processors implement the two behaviors,
controlled by some status bit somewhere.

The first problem is that there is no standard C API to select the
desired behavior (even ISO C 99 isn't terribly clear on this).  So,
everyone stays in the "nans, no traps" mode.

> Here's another question:  is it possible to catch floating point
> exceptions such as division by zero?  It seems like that might be another
> way of dealing with this.  I thought catching SIGFPE would do it, but I
> tried and I couldn't seem to get it triggered.  Is it possible to convert
> floating point exceptions to ocaml exceptions?

That's the second problem.  Trapping a synchronous signal (such as
SIGFPE) and turning it into a Caml exception is quite hard and
non-portable.  Caml manages to deal with asynchronous signals by
delaying their delivery until a safe point is reached, but obviously
this doesn't work for synchronous, program-generated signals.  
E.g. what to do if the SIGFPE comes from C code running in "blocking
section" mode?

- 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