Hi Christian,

I'm far from being at the level of Caml implementors but:

Christian Lindig <lindig@eecs.harvard.edu> writes:

>     # let nan x = not (x = x);;
>     val nan : 'a -> bool = <fun>
                ^^ here you have a polymorphic equality test
>     # nan (1.0 /. 0.0);;
>     - : bool = false            (* correct *)
>     # nan (0.0 /. 0.0);;
>     - : bool = false            (* should be true *)
> 
> The following definition of nan uses a type annotation and has a
> different result:
> 
>     # let nan (x:float) = not (x = x);;
>     val nan : float -> bool = <fun>
                ^^^^^ here we know that we have floats
>     # nan (0.0 /. 0.0);;
>     - : bool = true             (* correct *)
>     # nan (1.0 /. 0.0);;
>     - : bool = false            (* correct *)
> 
> Is this a bug or a feature? Anyway, I guess this again shows the subtleties
> of equality.

I would say a feature. As Xavier said in his mail[1], if the compiler
knows that in *every case* we have a float, it generates a float
specific comparison code. Otherwise, the compiler takes the safe way by
using a generic comparison operator.

You can see this with an undocumented option of the bytecode compiler:

pochi(mentre):~ [976] ocaml -dinstr
        Objective Caml version 3.00

# let nan x = not (x = x);;
[...]
	ccall equal, 2
[...]
val nan : 'a -> bool = <fun>

# let nan (x:float) = not (x = x);;
[...]
	ccall eq_float, 2
[...]
val nan : float -> bool = <fun>


If you look at assembly code, you'll see the same behavior:

pochi(mentre):/tmp [1008] cat nan.ml
let nan_poly x = not (x = x)

let nan_float (x:float) = not (x = x)

pochi(mentre):/tmp [1009] ocamlopt -S nan.ml
pochi(mentre):/tmp [1010] cat nan.s
[...]
Nan_nan_poly_43:
.L100:
	pushl	%eax
	pushl	%eax
	movl	$equal, %eax
	call	caml_c_call
        ^^^^^^^^^^^^^^^^^^^ the compiler call a generic
                            (i.e. polymorphic equality operator)
[...]
Nan_nan_float_45:
	subl	$8, %esp
.L104:
	fldl	(%eax)
	fldl	(%eax)
	fucompp
        ^^^^^^^ float specific comparison operation, with NaN handling,
                see [2]
[...]


Hope it clarifies,
david

[1] http://caml.inria.fr/archives/200101/msg00195.html
[2] http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/CH14/CH14-5.html#HEADING5-22
-- 
 David.Mentre@inria.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.