strictly less-than (Re: [erlang-questions] Ordered set and DETS) - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion strictly less-than (Re: [erlang-questions] Ordered set and DETS)
Received-SPF: pass (google.com: domain of erlang-questions-return-53178-erlang-programming+garchive-81772=googlegroups....@erlang.org designates 193.180.168.22 as permitted sender) client-ip=193.180.168.22;
Mailing-List: contact erlang-questions-h...@erlang.org; run by ezmlm
Sender: <erlang-questi...@erlang.org>
Precedence: bulk
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=KKrJHv29/4NewAfFuLDA8Gem+en7/nXpC1z4WJkPeHZbC1EqFrfFTavqPQaPjrIlQq
         V91jzmIu5al5As+A7AjoRYOsi6ikiz1JanvG73x4xE6xbtY7pB/va36u44DiKlZhLxaB
         hCA1GSGUSFIfp8D/9UPmn+hSGQV7Q8SSziAZc=
MIME-Version: 1.0
In-Reply-To: <4C84D6E8.2080...@erlang-solutions.com>
References: <B293D35E9E20694A8D9DFFE1BC655C556479234...@vvexch.verivue.com>
	<4C827ED3.7080...@erlang-solutions.com>
	<4C84D6E8.2080...@erlang-solutions.com>
Date: Mon, 6 Sep 2010 11:03:39 -0400
Message-ID: <AANLkTi=4XETunC2zwpo6bb-qKJcpEgBR0HT7aG8q+...@mail.gmail.com>
From: Nicholas Frechette <zeno...@gmail.com>
To: Ulf Wiger <ulf.wi...@erlang-solutions.com>
Cc: erlang-questi...@erlang.org
Content-Type: multipart/alternative; boundary=e0cb4e887865ec56ee048f9895d6
Subject: Re: [erlang-questions] strictly less-than (Re: [erlang-questions]
 Ordered set and DETS)

--e0cb4e887865ec56ee048f9895d6
Content-Type: text/plain; charset=ISO-8859-1

Is that not the expected behavior per the erlang doc?
http://www.erlang.org/doc/reference_manual/expressions.html
Section 7.11 Term Comparisons (copied below the simplicity)

Lists are compared element by element. Tuples are ordered by size, two
tuples with the same size are compared element by element.

If one of the compared terms is an integer and the other a float, the
integer is first converted into a float, unless the operator is one of =:=
and =/=. If the integer is too big to fit in a float no conversion is done,
but the order is determined by inspecting the sign of the numbers.

Returns the Boolean value of the expression, true or false.
afaik, 1==1.0 -> true and 1=:=1.0 -> false makes sense to me. This means
that of course, you can't trust =:= for ordering elements.
Conceptually speaking, comparing floating points and integers, one can only
infer an ordering if one converts one into the other since ordering is only
defined within each's realm.

Incidentaly, what would you expect of the following:
1 < {foo, 2}
1 > {foo, 2}
1 == {foo, 2}
1 =:= {foo, 2}

IMO a better way to define an ordering in a case like these, when sorting,
would be to pass a function that defines the ordering based on input values.

I'm not sure extending the language makes sense here.
2cents
Nicholas

On Mon, Sep 6, 2010 at 7:56 AM, Ulf Wiger <ulf.wi...@erlang-solutions.com>wrote:

>
> So when exercising my QuickCheck suite for the sext
> (sortable serialization) library, I stumbled upon an intermittent
> test case failure, which was particularly vexing.
>
> The failing case was the sorting property, which says that,
> for any terms, comparing the encoded terms should yield
> the same result as comparing the original terms.
>
> The failing term pairs are {-1.0, 1}, {1.0, 1}, {2.0, 2} etc.
> The terms are not strictly equal, so they have to be encoded
> differently (otherwise, the encoding property breaks).
> That is, decode(encode(2.0)) =:= 2.0 must hold true*.
> In this sense, the values in each pair are distinctly different.
>
> * For some definition of true. In the case of sext, I specify that
> the IEEE 754 binary64 representation of the float, as used in
> the bit syntax notation, must be the same.
>
> Yet, they have no defined ordering!
>
> Eshell V5.7.5  (abort with ^G)
> 1> 1 < 1.0.
> false
> 2> 1.0 < 1.
> false
> 3> 1.0 =:= 1.
> false
>
> This means that the result of lists:sort/1 is not defined in this
> particular case:
>
> Eshell V5.7.5  (abort with ^G)
> 1> lists:sort([1,1.0]).
> [1,1.0]
> 2> lists:sort([1.0,1]).
> [1.0,1]
>
> Naturally, lists:usort/1 has a corresponding behaviour:
>
> 3> lists:usort([2,2.0]).
> [2]
> 4> lists:usort([2.0,2]).
> [2.0]
>
>
> I think this is a good argument in favour of adding operators
> "strictly <" and "strictly >", which I suggest could be :< and >:.
>
> I made a simple hack where the parser recognized these tokens and
> expanded it into something similar to:
>
> ':<'(A,B) ->
>    A == B
>        andalso (is_integer(A)
>                 andalso is_float(B))
>        orelse A < B.
>
> '>:'(A,B) ->
>    A == B
>        andalso (is_float(A)
>                 andalso is_integer(B))
>        orelse A < B.
>
> but rather as a form rewriting excercise in erl_parse.yrl:
>
> wrap_op({op,Pos,':<',L,R}) ->
>    {op,Pos,'orelse',
>     {op,Pos,'andalso',
>         {op,Pos,'==',L,R},
>         {op,Pos,'andalso',
>             {call,13,{atom,Pos,is_integer},[L]},
>             {call,14,{atom,Pos,is_float},[R]}}},
>     {op,Pos,'<',L,R}};
> wrap_op({op,Pos,'>:',L,R}) ->
>    {op,Pos,'orelse',
>     {op,Pos,'andalso',
>         {op,Pos,'==',L,R},
>         {op,Pos,'andalso',
>             {call,13,{atom,Pos,is_float},[L]},
>             {call,14,{atom,Pos,is_integer},[R]}}},
>     {op,Pos,'>',L,R}};
> wrap_op(Op) ->
>    Op.
>
>
> This way, it works in guards as well, and will be BW
> compatible with existing tools, but with the disadvantage
> that the original source cannot be reconstituted.
>
> I could try to formulate this as an EEP, if you all think
> it's a reasonable (although quite marginal) suggestion.
>
> An alternative would be to re-formulate the property of sext
> such that the encoded terms sort the same way as the original
> terms in all cases where it is reasonable to rely on the sort
> order in the first place. This is to some extent already true,
> at least in regard to encode/decode symmetry, in other cases
> involving floats. This alternative likely has less impact. :)
>
> BR,
> Ulf W
>
> On 09/04/2010 07:16 PM, Ulf Wiger wrote:
> > On 09/03/2010 10:28 PM, Evans, Matthew wrote:
> >> Hi,
> >>
> >> Does anyone know if there are any roadmap plans to implement ordered_set
> table types in DETS?
> >>
> >> Thanks
> >
> > It may be possible to build on the combination of Tokyo Tyrant
> > and my sortable serialization library, which I mentioned in
> > this post a while ago:
> >
> > http://www.erlang.org/cgi-bin/ezmlm-cgi/4/47285
> >
> > That was part of the justification for adding prefix
> > matching and matchspec-style functionality in the sext
> > library in the first place.
> >
> > BR,
> > Ulf W
> >
> >
> > ________________________________________________________________
> > erlang-questions (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
> >
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscr...@erlang.org
>
>

--e0cb4e887865ec56ee048f9895d6--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
