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

Fri Feb 8 19:53:30 UTC 2019

> minBound + minBound :: Int
0
> negate minBound == (minBound :: Int)
True
> 42 + negate 17 :: Word
25

Int and Word are currently rings. What proportion actually uses them as
such would be interesting to know but I guess it is very small. I wouldn't
dare to reason about Int and Word as rings as there is no guarantee on
which ring they are. Int64 and Word64 and so on; yes, those can be reasoned
about.

I'd be very happy to see a separate type for signalling integral types.
Personally, I'd make them the default choice.

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

> I’m not sure if they currently have full ring structure , but  I do agree
> that trapping and non trapping int and word are useful.
>
> Simple example where all the finite signed ints work wrong today :
>
> There’s no proper additive inverse for minBound :: int
>
> Likewise , what’s our current definition of negate on finite word types?
>
> On Fri, Feb 8, 2019 at 2:12 PM David Feuer <david.feuer at gmail.com> wrote:
>
>> No, no, no. Int and Word are *rings*, which let's us apply a ton of
>> mathematical reasoning to their arithmetic. Trapping overflow would throw
>> all that completely out the window. If you want to trap overflow, please
>> use different types!
>>
>> On Fri, Feb 8, 2019, 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
>>>>
>>> _______________________________________________
>>> 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/6cfc83aa/attachment.html>