<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Answers inline ..</div><div class="gmail_quote"><br></div><div class="gmail_quote">2015-03-24 23:00 GMT+01:00 Jesper Louis Andersen <span dir="ltr"><<a href="mailto:jesper.louis.andersen@gmail.com" target="_blank">jesper.louis.andersen@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 3:28 PM, Björn-Egil Dahlberg <span dir="ltr"><<a href="mailto:egil@erlang.org" target="_blank">egil@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We will look into the others now.</blockquote></div><br></span>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:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">Erlang/OTP 17 [erts-6.3.1] [source-a1520d8] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]</div><span class=""><div class="gmail_extra"><br></div><div class="gmail_extra">Eshell V6.3.1  (abort with ^G)</div></span><div class="gmail_extra">1> L = [{-1,0},{0.0,0},{0,0},{1,0}].</div><div class="gmail_extra">[{-1,0},{0.0,0},{0,0},{1,0}]</div><div class="gmail_extra">2> lists:sort(L).</div><div class="gmail_extra">[{-1,0},{0.0,0},{0,0},{1,0}]</div><div class="gmail_extra">3> lists:sort(maps:to_list(maps:from_list(L))).</div><div class="gmail_extra">[{-1,0},{0,0},{0.0,0},{1,0}]</div><div class="gmail_extra">4> v(2) =:= v(3).</div><div class="gmail_extra">false</div><div class="gmail_extra"><div class="gmail_extra">5> maps:to_list(maps:from_list(L)).</div><div class="gmail_extra">[{-1,0},{0,0},{1,0},{0.0,0}]</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>I don't think anything is wrong here.</div><div><br></div><div>Maps (small maps) store keys in "term order" not "arithmetic order". Where "term order" is defined as erlangs arithmetic order but integers types are less than float types. This gives us a total order of all erlang terms.<br></div><div><br></div><div>Furthermore, maps:to_list/1 is defined to return pairs in arbitrary order. =)</div><div><br></div><div>v(2) =:= v(3) returns false because lists:sort/1 is stable, 0.0 and 0 compares equal and those keys started in different positions before the sort.</div><div><br></div><div>However, we will change map comparison between maps to 18. Two maps will compare keys by term order and not by arithmetic order as it is today. Values will still use arithmetic order.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br clear="all"><div>Also, another peculiar thing:</div><div><br></div><div><div>7> maps:put(-1, 3, #{}). </div><div>#{-1 => 3}</div><div>8> #{ -1 => 3 }.</div><div>* 1: illegal map key</div></div><div><br></div><div>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 :)</div></div></div></blockquote><div><br></div><div>This is a (not so) known fact. It has to do with the fact that we only handle literal keys with maps syntax in 17 and negative integers are not literals. They are unary expressions on positive integers and thusly not handled by the compiler.</div><div>This is not the case in 18 (current master) where we can handle map keys with variables.</div><div><br></div><div> // Björn-Egil</div></div></div></div>