Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

[Carter Schonwald]

Thanks for eloquently summarizing , better than I would , what I thought I
had laid out.

Ieee floating point has fantastic hardware support .  May as well be the
first real language to actually use it correctly. :)

On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten <merijn at inconsistent.nl>
wrote:

>
>
> > On 8 Feb 2019, at 10:57, Sven Panne <svenpanne at gmail.com> wrote:
> >
> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten <
> merijn at inconsistent.nl>:
> > Our goal is to make "compare NaN n" impossible to happen. [...]
> >
> > Well, what is supposed to happen then when you *do* see a NaN, e.g. one
> produced from a foreign call? You *will* see NaNs in Haskell if you
> interact with other languages, most of them take a far less religious
> approach to floating points calculations.
>
> This is not true. As Carter pointed out we can setup the CPU to trap NaNs
> *even in foreign calls*. So, in theory we CAN rule this out safely. Doing
> this we can simply convert the trap into an exception at the FFI boundary.
>
> Now, there are cases were this is problematic, so as said before we will
> probably need to allow people to optionally switch on 'value NaNs', because
> the foreign code isn't exception safe or for other reasons, but this is
> manageable. Via, for example having an annotation on foreign imports
> whether you want to trap or not.
>
> In the scenario where someone switches to value NaNs, we are *still* not
> worse off than we are now. The things you suggest already happen *now*, so
> the only thing we're advocating is making it possible to have more sane
> behaviour in the future.
>
> Any IEEE-754 compliant implementation of Double that doesn't use trapping
> NaN can, by definition, never ever be a sane implementation of Ord. As
> IEEE-754 *requires* "NaN /= NaN", so equality symmetry doesn't apply to
> NaNs and there is *no* safe way to sort/order data containing NaNs.
>
> I've run into several nasty issues of trying to sort lists containing NaNs
> (not just Haskell, also Python and C) and it's *not* just the NaNs that are
> affected, entire subsequences end up getting sorted wrong based on the
> comparison with NaN and you end up with completely garbled and unsorted
> data.
>
> In other words, there are only two ways to get sane behaviour from Double
> with regards to ordering:
>
> 1. Trapping NaN represenation
> 2. Deviate from IEEE-754 semantics
>
> To me, option 2 is out of the question, it's the one consistent thing
> across language we have when it comes to floating point. I understand that
> *always* using trap representation isn't feasible, but allowing people to
> optionally switch to value NaNs leaves us no worse off than we are *right
> now*, and per above, there is literally no way to improve the situation wrt
> value NaNs without sacrificing IEEE-754 compliance.
>
> Cheers,
> Merijn
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190208/dfe89168/attachment.html>