Make phys_equal more like native

[hhugo]

Fix #1372

[hhugo]

This change revealed some issues with some js stubs what were returning -0 instead of 0.

[hhugo]

@ty, is there any per difference between the two ? Is object.is available everywhere?

[TyOverby]

https://caniuse.com/mdn-javascript_builtins_object_is

It’s pretty widely supported!

[TyOverby]

As for performance impacts, I don't have a good intuition for if it would be faster or slower. A small microbenchmark that I just made seems to indicate that Object.is is faster

[hhugo]

some other seems to show that === is faster (when inputs are ints and array, which should be the common case).

[hhugo]

I'm not really happy with the current implementation, mostly because the decision to use === or Object.is is syntactic.
@vouillon, any opinion ?

[hhugo]

I'm not really happy with the current implementation, mostly because the decision to use === or Object.is is syntactic. @vouillon, any opinion ?

I've changed the implementation. We now keep track of whether Eq and Neq compare float or non-float values.

[vouillon]

I'm not sure how much of a difference this PR makes. In most cases, the physical equality will still not behave the same. For instance, this will still return true with Js_of_ocaml:

# 0. == 0.;;
- : bool = false

[hhugo]

I'm not sure how much of a difference this PR makes. In most cases, the physical equality will still not behave the same. For instance, this will still return true with Js_of_ocaml:

# 0. == 0.;;
- : bool = false

The most interesting bit is "fixing" phys_equal between 0. and -0..
The rest (whether two identical float are equal or not) can been seen as an implementation detail.

That said, looking at the documentation of ==, 0. == -0. is fine.

   On non-mutable types, the behavior of [( == )] is
   implementation-dependent; however, it is guaranteed that
   [e1 == e2] implies [compare e1 e2 = 0].

[hhugo]

replaced by #1745