I tried a solution based on Xavier's suggestion, and it now looks to me
like Xavier's suggsetion (or my implementation) is unsafe.  Here's the
code I tried:

let is_obj_nan x =
  Obj.tag (Obj.repr x) = Obj.double_tag &&
  (let f = (Obj.magic x : float) in not (f = f))

let min x y =
  if is_obj_nan x then x
  else if is_obj_nan y then y
  else Pervasives.min x y

let max x y =
  if is_obj_nan x then x
  else if is_obj_nan y then y
  else Pervasives.max x y;;

The resulting code segfaulted on me, and the segfault went away when I
went back to the ordinary min and max.  Does anyone have a thought on
this?  Is this use of Obj safe or not?

I'm still trying to debug the actual location of the segfault, but the
lack of stacktraces makes it a bit harder....

y

>> Now here's the weird bit.  I decided I wanted a polymorphic comparison
>> that wouldn't have this problem.  But this is a little harder than it
>> seems, since it turns out that specialized float version of equality is
>> different from the polymorphic version.
>
> Yes, it's a long-standing bug for which we haven't yet a good
> solution.  More exactly, there are two problematic solutions:
>
> 1- Fix polymorphic equality so that it behaves like IEEE equality on
> floats,
> i.e. it always returns false when one of its arguments is NaN.
> The problem is that this breaks the implication
>         x == y  imply  x = y
> and thus the current implementation of polymorphic equality needs to
> be made less efficient.  Currently, x = y starts by testing x == y
> and returns true if the pointer equality holds.  But this could be the
> wrong result according to the new specification, since x can contain
> an NaN somewhere.  Hence, polymorphic equality would have to traverse
> its two arguments even when they are physically the same.  The
> performance impact of this change on real programs is unknown.
>
> 2- As J M Skaller proposed, change the behavior of polymorphic
> equality and its version specialized to floats so that nan = nan
> and nan <> x if x <> nan.  Similar changes need to be done on the
> <>, <= and >= tests for consistency.  IEEE comparisons would then have to
> be
> provided as separate primitives.  This preserves the implication
> x == y ==> x = y.  But the machine code generated for =, <>, <= and >=
> over floats will have to be a lot less efficient than it is now, since
> all processors implement float comparisons as per IEEE.
>
> Coming back to your proposed workaround:
>
>> # let raw_min = min
>> val raw_min : 'a -> 'a -> 'a = <fun>
>> # let min x y =
>>   if not (y = y) then y
>>   else if not (x = x) then x
>>   else raw_min x y
>> ;;
>
> A way to make this work would be to replace the "not (x = x)" tests
> by calls to the following function (of type 'a -> bool):
>
> let is_obj_nan x =
>   Obj.tag (Obj.repr x) = Obj.double_tag &&
>   (let f = (Obj.magic x : float) in not (f = f))
>
> Not pretty, I agree.
>
> - 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
>

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