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

[Carter Schonwald]

Hey Ganesh,
because of how float stuff works, the code generated will be the same
either way.

On Sun, Feb 10, 2019 at 4:17 PM Ganesh Sittampalam <ganesh at earth.li> wrote:

> 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
> >
>
> _______________________________________________
> 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/20190211/31ab5913/attachment.html>