Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Are you sure the new "=" of 3.08 is good ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-10-08 (15:54)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: [Caml-list] Are you sure the new "=" of 3.08 is good ?
> I spend one complete day to adapt Phox (my theorem prover) to 3.08
> because the new = does not check first physical equality. Hopefully, the 
> backtracking ocamldebugger let me pin point the many "=" which were 
> looping, otherwise I would have spend a month !!!

If you get non-termination with the = comparison in 3.08, it means
your program is comparing cyclic data structures, which could also
have caused looping with the old = comparison.  It's just that the new =
loops "more easily" than the old one.  But I would argue that your
original code was living dangerously close to the edge.  Don't feel
bad: in developing 3.08 we found several instances of misuses of =
over cyclic structures (types) in the OCaml compiler...

> I was assuming two things about equal:
> - scan of block from left to right
> - a test on adress equality on pointer before follwing the pointer 
> (which is now wrong in 3.08).

That was true of the old implementation, but has never been guaranteed.

As others mentioned, you can recover the behaviour above in 3.08
(it also works in earlier releases) as follows:

let (=?) x y = ( x y = 0)

and use =? instead of = where appropriate.

> So the comparison between both "=" gives
> old "=":
> - can have much better complexity of some specific data structure
> - nan = nan => true
> new "="
> - can have a small linear speedup on some specific data structure
> - nan = nan => false

You're missing the essential point: the old "=" was inconsistent over
floats, i.e. you'd get different results from the generic = and the
type-specialized = over floats.  Semantic consistency takes precedence
over efficiency.

> Finally, the IEEE norm about floating point arithmetic is not perfect 
> yet.

Maybe not, but it's a consensus that took umpteenth years to achieve
(and got Kahan a Turing award), so one needs very very strong reasons
to depart from it.  

- Xavier Leroy

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: