Re: Maps equality failure / Maps merge failure

On Tue, Mar 24, 2015 at 3:28 PM, Björn-Egil Dahlberg <[email protected]>
wrote:

> We will look into the others now.


I extended the tests for the branch egil/fix-term-cmp/OTP-12623 (commit-ID:
a1520d8) which fixes the binary_to_term/term_to_binary conversions. I had
some model errors with maps:map/2, which I fixed. Then I added generators
for floating point values. Look at this little gem:

Erlang/OTP 17 [erts-6.3.1] [source-a1520d8] [64-bit] [smp:8:8]
[async-threads:10] [hipe] [kernel-poll:false]

Eshell V6.3.1  (abort with ^G)
1> L = [{-1,0},{0.0,0},{0,0},{1,0}].
[{-1,0},{0.0,0},{0,0},{1,0}]
2> lists:sort(L).
[{-1,0},{0.0,0},{0,0},{1,0}]
3> lists:sort(maps:to_list(maps:from_list(L))).
[{-1,0},{0,0},{0.0,0},{1,0}]
4> v(2) =:= v(3).
false
5> maps:to_list(maps:from_list(L)).
[{-1,0},{0,0},{1,0},{0.0,0}]

In other words, factoring L through a map makes the comparison and the sort
go wrong. I would expect the factoring to be the identity such that v(4)
would be true in the above. But it looks like something happens to the
value so 0 and 0.0 swaps place in the ordering. There *has* to be a
floating point 0.0 in there. So it has something to do with this, but I
can't be more specific :) Note that this bug may be related to the merge
bug I reported earlier today, but the merge tests succeed on this branch.

Also, another peculiar thing:

7> maps:put(-1, 3, #{}).
#{-1 => 3}
8> #{ -1 => 3 }.
* 1: illegal map key

Negative integers are not valid map keys, but I don't know exactly why that
is the case. This is compiler-land however, and I have not yet a QuickCheck
model for that :)

Here is the QuickCheck run, including shrinking:

https://gist.github.com/jlouis/5b4311f40675b1693c84


-- 
J.

_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs