Re: Maps equality failure / Maps merge failure

On 03/25/2015 04:17 PM, Ulf Wiger wrote:
>> >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).
>

Not familiar with 'sext' encoding, but I am not sure I get the details 
in the problem you run into...  For once, I do not see any use of 
lists:sort/1 here.  Is it buried in the comp*/2 functions somehow?  Does 
comp/2 use arithmetic rather than term comparison ?

Or can it simply be that the reason the "intuitive" property cannot be 
used is because you have used ==/2 instead of =:=/2 there?

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