Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report
Vanessa McHale
vanessa.mchale at iohk.io
Fri Feb 8 19:32:35 UTC 2019
Most of the arguments for making them rings feel kind of pedantic, in
any case. I can't think of a time I've ever used actual ring theory to
reason about Ints/Words.
On 2/8/19 1:27 PM, Carter Schonwald 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
> <mailto: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 <mailto: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
> <mailto: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 <mailto:merijn at inconsistent.nl>>
> wrote:
>
>
>
> > On 8 Feb 2019, at 10:57, Sven Panne
> <svenpanne at gmail.com <mailto:svenpanne at gmail.com>> wrote:
> >
> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn
> Verstraaten <merijn at inconsistent.nl
> <mailto: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 <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto:Libraries at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org <mailto: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/a938c52b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190208/a938c52b/attachment.sig>
More information about the Libraries
mailing list