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

Fri Feb 8 20:26:15 UTC 2019

Yes, but a ring is sufficient for lots of very basic and important
manipulations. When I'm writing code with Int and Word, I don't even think
about whether the associative and distributive laws apply--I just use them
to simplify my definitions. With trapping overflow, I need to watch for
ranges every time I apply one. Horrible!

On Fri, Feb 8, 2019, 3:05 PM Carter Schonwald <carter.schonwald at gmail.com
wrote:

> I think the algebraic property we usually want for nice integer ish things
> is intergral domain. Which is a stronger property than ring. Pardon the
> confusion
>
> On Fri, Feb 8, 2019 at 3:03 PM Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> No.  A ring can’t have 2x=0 for x not zero.  Thus int can’t  be
>>
>> And by ring I mean an algebraic structure where you have a multiplicative
>> group that doesn’t generate zero from products of nonzero elements ...
>>
>> Phrased differently: Int doesn’t have a multiplicative group structure on
>> the nonzero elements. That makes it a pretty nasty ring. Negate on minBound
>> should be an overflow exception so you can have actual sane semantics.
>> This is an old dead horse with lots of blood written about it.
>>
>> https://ghc.haskell.org/trac/ghc/ticket/8695 has some related
>> discussions
>>
>>
>> On Fri, Feb 8, 2019 at 2:53 PM Jens Blanck <jens.blanck at gmail.com> wrote:
>>
>>> > 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
>>>>
>>> _______________________________________________
> 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/86a97823/attachment-0001.html>