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