Sorting NaNs

[Richard Damon]

On 6/2/18 4:51 PM, Ben Bacarisse wrote:
> Paul Rubin <no.email at nospam.invalid> writes:
>
>> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>>> it too will mess up sorting in unpredictable ways. So don't do that.
>> Hmm.  GHCi 7.4.2:
>>
>>     Prelude> let x = 0.0 / 0.0
>>     Prelude> x
>>     NaN
>>     Prelude> x==x
>>     False
>>     Prelude> :m Data.List
>>     Prelude Data.List> sort [1,2,x,4,5]
>>     [1.0,2.0,4.0,5.0,NaN]
> But
>
>   Prelude Data.List> sort [1,x,2,4,5]
>   [2.0,4.0,5.0,NaN,1.0]
>
> and
>
>   Prelude Data.List> sort [1,2,x,4,5,x]
>   [NaN,1.0,2.0,4.0,5.0,NaN]
>
> and
>
>   Prelude Data.List> sort [1,2,x,4,5,x,1/0]
>   [1.0,2.0,4.0,Infinity,NaN,5.0,NaN]
>
>> Not sure what to make of this but at least sorting seems to give a
>> predictable result.
> I suspect it is predictable if you know the algorithm, but I doubt it's
> specified nor easily guessable from "outside".
>
> (GHCi, version 8.0.2 here)
>
The sorting algorithm is almost certainly deterministic (as is the
comparisons with Nan), so given the same input you will get the same
output, which says you could predict the output by effectively running
the sort and look at the results and predict it will happen the same,
this presumes you know the exact implementation of the sort (which you
could get from the implementation source code). This could be called
'predictable' but that is a real stretch.


Because the sort is stable, I would expect that away from the Nans in
the output the results are likely to be at least mostly sorted, as the
algorithm should mostly be working right except where a NaN is moving
through.

-- 
Richard Damon