Sorting floating-point values, and NaN
tn
no at email.com
Tue Nov 12 13:03:01 PST 2013
On Tuesday, 12 November 2013 at 20:03:37 UTC, Andrei Alexandrescu
wrote:
> Consider we define equiv(a, b) as (a, b) => !less(a, b) &&
> !less(b, a).
>
> If at least one of the numbers is NaN, all comparisons return
> false. That puts NaN in the same equivalence class with all
> numbers, including numbers that are deemed in distinct
> equivalence classes. That's where NaNs mess things up, and
> that's what we need to assert. Consider three numbers a, b, and
> c. Then the following must pass:
>
> assert((equiv(a, b) && equiv(b, c)) <= equiv(a, c));
>
> ("<=" on Booleans is actually implication.)
Shouldn't the implication be to the other direction? Then it
becomes
assert((equiv(a, b) && equiv(b, c)) => equiv(a, c));
> That test will fail with NaNs and should be part of isSorted,
> sort etc.
But it requires that the input contains at least three elements.
And it has to test a lot of possible triples (a,b,c), which I
think requires at least O(n^2) time. And it does not fail
consistently whenever the input contains at least one NaN
(consider an input that contains only NaNs).
> We should also check such as:
>
> assert(!less(a, a));
> assert(less(a, b) <= !less(b, a));
>
> These should be checked in sort only; isSorted does not need
> these.
The latter fails also if a==b. (Unless the direction of the
implication is again wrong.)
More information about the Digitalmars-d
mailing list