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

[John Hughes]

I think this is a good idea... it's handy to have a real total ordering on 
values, which this would give. Then sort should be modified to use <: 
instead of <, which is very unlikely to cause any problems. But note there 
would need to be TWO versions of usort, one with (approximately) today's 
behaviour, and one giving uniqueness up to matching. musort, maybe?

John

----- Original Message ----- 
From: "Ulf Wiger" <ulf.wiger@REDACTED>
>
> 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 >:.
>