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

[Carter Schonwald]

I absolutely agree. Before any user visible stuff happens the first step
would be rts support for better managing floating point flags / rounding
mode / trap bits.

Could you list some contexts / examples where you want quiet or signaling
nans respectively?  The more examples written down and shared the better! :)

On Fri, Feb 8, 2019 at 2:07 PM Lennart Augustsson <lennart at augustsson.net>
wrote:

> 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/6fab39d0/attachment.html>