Re: Maps equality failure / Maps merge failure

> On 25 Mar 2015, at 00:16, Kostis Sagonas <[email protected]> wrote:
> 
> The above may seem a bit weird at first but is not at all strange given that lists:sort/1 does not sort according to the (total) term order:
> 
>  Eshell V6.3.1  (abort with ^G)
>  1> lists:sort([0, 0.0]).
>  [0,0.0]
>  2> lists:sort([0.0, 0]).
>  [0.0,0]

But this is according to the documented comparison semantics, surely.

From the Reference Manual:
"When comparing an integer to a float, the term with the lesser precision will be converted into the other term's type, unless the operator is one of =:= or =/=.”

It’s unfortunate though, and I ran into this issue when writing QuickCheck properties for the ‘sext’ encode/decode.

prop_sort() ->
    ?FORALL({T1,T2}, {term_(), term_()},
            begin
                {X1,X2} = {sext:encode(T1), sext:encode(T2)},
                comp(X1,X2) == comp_i(T1,T2)
            end).

…where comp_i/2 takes care of the case where X1 == X2, X1 =/= X2.

That is, the intuitive property could not be used, given that this also had to be satisfied:

prop_encode() ->
    ?FORALL(T, term_(),
            sext:decode(sext:encode(T)) == T).

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com



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