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

[Lennart Augustsson]

I would *hate* to lose quiet NaNs.  They can be very useful.  But I’d be
fine having them as a separate type.

And while we’re at it, why not make Int overflow and underflow cause a trap
as well?  With a different type if you want to wrap.


On Fri, Feb 8, 2019 at 08:34 Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> 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
>>
> _______________________________________________
> 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/f8868d03/attachment.html>