|Anonymous | Login | Signup for a new account||2017-11-18 00:11 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007502||OCaml||standard library||public||2017-03-09 10:36||2017-05-02 12:06|
|Target Version||Fixed in Version|
|Summary||0007502: (=) does not use physical equality unlike compare|
|Description||For some reason, I was playing with:|
let rec l = 1 :: l;;
And I tried to manipulate it. But while "compare l l" returns 0 instantaneously, "l = l" loops infinitely. I do not know if structural equality is supposed to use physical equality as a speed-up, but I find this difference in behaviour surprising. The same happens with (<) ad (>).
Moreover, in an interactive session (utop or ocaml), the loop is not interrupted by pressing ctrl+c.
|Tags||No tags attached.|
|Tested on 4.04.0.|
|There is at least a documentation mismatch between this behavior and the description of compare in the manual that claims compatibily between (=) and compare except for NaN.|
> I do not know if structural equality is supposed to use physical equality as a speed-up, but I find this difference in behaviour surprising.
`x = y` has a different semantics than `compare x y = 0`, and it cannot use physical equality as a "shortcut". The reason is related to floating points, for which `nan = nan` should be false even though the two arguments are physically equal, but one wants `compare nan nan` to return 0. And it has been decided that the same property should hold for nested floats as well, i.e. `let x = ("", nan) in x = x` should be false, but `let x = ("", nan) in compare x x` should be 0. Basically, (=) is *not* an equivalence relation (reflexivity does not hold) while `(fun x y -> compare x y = 0)` is (on its definition domain).
Honestly, I think it would be better to make (=) reflexive(and use physical equality as a short-cut) and to provide an explicit comparison function on floats using IEEE semantics. But I don't believe such proposal has any chance to be accepted. So I'm "resolving" this ticket for now.
|2017-03-09 10:36||eponier||New Issue|
|2017-03-09 10:37||eponier||Note Added: 0017606|
|2017-03-09 10:40||octachron||Relationship added||related to 0003921|
|2017-03-09 10:54||octachron||Priority||normal => low|
|2017-03-09 10:54||octachron||Status||new => confirmed|
|2017-03-09 10:54||octachron||Category||language features => standard library|
|2017-03-09 10:56||octachron||Note Added: 0017607|
|2017-03-09 11:05||frisch||Note Added: 0017608|
|2017-03-09 11:05||frisch||Status||confirmed => resolved|
|2017-03-09 11:05||frisch||Resolution||open => won't fix|
|2017-03-09 11:05||frisch||Assigned To||=> frisch|
|2017-05-02 12:06||dra||Relationship added||related to 0007524|
|Copyright © 2000 - 2011 MantisBT Group|