<div dir="ltr"><div dir="auto">Hey Ganesh,</div><div>because of how float stuff works, the code generated will be the same either way.</div></div><div><br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 10, 2019 at 4:17 PM Ganesh Sittampalam <<a href="mailto:ganesh@earth.li" target="_blank">ganesh@earth.li</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Wouldn't having both quiet and signalling NaN types imply wrapping all<br>
the primitive operations for one or other type in a CPU state switch?<br>
Maybe the compiler could then optimise some away.<br>
<br>
On 08/02/2019 19:07, Lennart Augustsson wrote:<br>
> I would *hate* to lose quiet NaNs. They can be very useful. But I’d be<br>
> fine having them as a separate type.<br>
> <br>
> And while we’re at it, why not make Int overflow and underflow cause a<br>
> trap as well? With a different type if you want to wrap. <br>
> <br>
> <br>
> On Fri, Feb 8, 2019 at 08:34 Carter Schonwald<br>
> <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a> <mailto:<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>>> wrote:<br>
> <br>
> Thanks for eloquently summarizing , better than I would , what I<br>
> thought I had laid out. <br>
> <br>
> Ieee floating point has fantastic hardware support . May as well be<br>
> the first real language to actually use it correctly. :)<br>
> <br>
> On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten<br>
> <<a href="mailto:merijn@inconsistent.nl" target="_blank">merijn@inconsistent.nl</a> <mailto:<a href="mailto:merijn@inconsistent.nl" target="_blank">merijn@inconsistent.nl</a>>> wrote:<br>
> <br>
> <br>
> <br>
> > On 8 Feb 2019, at 10:57, Sven Panne <<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a><br>
> <mailto:<a href="mailto:svenpanne@gmail.com" target="_blank">svenpanne@gmail.com</a>>> wrote:<br>
> ><br>
> > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten<br>
> <<a href="mailto:merijn@inconsistent.nl" target="_blank">merijn@inconsistent.nl</a> <mailto:<a href="mailto:merijn@inconsistent.nl" target="_blank">merijn@inconsistent.nl</a>>>:<br>
> > Our goal is to make "compare NaN n" impossible to happen. [...]<br>
> ><br>
> > Well, what is supposed to happen then when you *do* see a NaN,<br>
> e.g. one produced from a foreign call? You *will* see NaNs in<br>
> Haskell if you interact with other languages, most of them take<br>
> a far less religious approach to floating points calculations.<br>
> <br>
> This is not true. As Carter pointed out we can setup the CPU to<br>
> trap NaNs *even in foreign calls*. So, in theory we CAN rule<br>
> this out safely. Doing this we can simply convert the trap into<br>
> an exception at the FFI boundary.<br>
> <br>
> Now, there are cases were this is problematic, so as said before<br>
> we will probably need to allow people to optionally switch on<br>
> 'value NaNs', because the foreign code isn't exception safe or<br>
> for other reasons, but this is manageable. Via, for example<br>
> having an annotation on foreign imports whether you want to trap<br>
> or not.<br>
> <br>
> In the scenario where someone switches to value NaNs, we are<br>
> *still* not worse off than we are now. The things you suggest<br>
> already happen *now*, so the only thing we're advocating is<br>
> making it possible to have more sane behaviour in the future.<br>
> <br>
> Any IEEE-754 compliant implementation of Double that doesn't use<br>
> trapping NaN can, by definition, never ever be a sane<br>
> implementation of Ord. As IEEE-754 *requires* "NaN /= NaN", so<br>
> equality symmetry doesn't apply to NaNs and there is *no* safe<br>
> way to sort/order data containing NaNs.<br>
> <br>
> I've run into several nasty issues of trying to sort lists<br>
> containing NaNs (not just Haskell, also Python and C) and it's<br>
> *not* just the NaNs that are affected, entire subsequences end<br>
> up getting sorted wrong based on the comparison with NaN and you<br>
> end up with completely garbled and unsorted data.<br>
> <br>
> In other words, there are only two ways to get sane behaviour<br>
> from Double with regards to ordering:<br>
> <br>
> 1. Trapping NaN represenation<br>
> 2. Deviate from IEEE-754 semantics<br>
> <br>
> To me, option 2 is out of the question, it's the one consistent<br>
> thing across language we have when it comes to floating point. I<br>
> understand that *always* using trap representation isn't<br>
> feasible, but allowing people to optionally switch to value NaNs<br>
> leaves us no worse off than we are *right now*, and per above,<br>
> there is literally no way to improve the situation wrt value<br>
> NaNs without sacrificing IEEE-754 compliance.<br>
> <br>
> Cheers,<br>
> Merijn<br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <mailto:<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a>><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
> <br>
> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
> <br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>