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 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 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 On 8 Feb 2019, at 10:57, Sven Panne Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten <
merijn@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries