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

[Ganesh Sittampalam]

Wouldn't having both quiet and signalling NaN types imply wrapping all
the primitive operations for one or other type in a CPU state switch?
Maybe the compiler could then optimise some away.

On 08/02/2019 19:07, Lennart Augustsson 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
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>