<div><div dir="auto">I think the algebraic property we usually want for nice integer ish things is intergral domain. Which is a stronger property than ring. Pardon the confusion </div></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 8, 2019 at 3:03 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">No. A ring can’t have 2x=0 for x not zero. Thus int can’t be </div></div><div dir="auto"><br></div><div dir="auto">And by ring I mean an algebraic structure where you have a multiplicative group that doesn’t generate zero from products of nonzero elements ... </div><div dir="auto"><br></div><div dir="auto">Phrased differently: Int doesn’t have a multiplicative group structure on the nonzero elements. That makes it a pretty nasty ring. Negate on minBound should be an overflow exception so you can have actual sane semantics. This is an old dead horse with lots of blood written about it. </div><div dir="auto"><br></div><div dir="auto"><div><a href="https://ghc.haskell.org/trac/ghc/ticket/8695" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/8695</a> has some related discussions </div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 8, 2019 at 2:53 PM Jens Blanck <<a href="mailto:jens.blanck@gmail.com" target="_blank">jens.blanck@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif"><span style="font-family:monospace"><span style="color:rgb(0,0,0)">> minBound + minBound :: Int
</span><br>0<br>
</span><span style="font-family:monospace"><span style="color:rgb(0,0,0)">> negate minBound == (minBound :: Int)
</span><br>True<br>
</span><span style="font-family:monospace"><span style="color:rgb(0,0,0)">> 42 + negate 17 :: Word
</span><br>25<br>
<br></span></div><div class="gmail_default"><font face="georgia, serif">Int and Word are currently rings. What proportion actually uses them as such would be interesting to know but I guess it is very small. I wouldn't dare to reason about Int and Word as rings as there is no guarantee on which ring they are. Int64 and Word64 and so on; yes, those can be reasoned about.</font></div><div class="gmail_default"><font face="georgia, serif"><br></font></div><div class="gmail_default"><font face="georgia, serif">I'd be very happy to see a separate type for signalling integral types. Personally, I'd make them the default choice.</font></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Feb 2019 at 19:27, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</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"><div><div dir="auto">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. </div></div><div dir="auto"><br></div><div dir="auto">Simple example where all the finite signed ints work wrong today : </div><div dir="auto"><br></div><div dir="auto">There’s no proper additive inverse for minBound :: int </div><div dir="auto"><br></div><div dir="auto">Likewise , what’s our current definition of negate on finite word types?</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 8, 2019 at 2:12 PM David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</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"><div dir="auto">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!</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson <<a href="mailto:lennart@augustsson.net" target="_blank">lennart@augustsson.net</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"><div><div dir="auto">I would *hate* to lose quiet NaNs. They can be very useful. But I’d be fine having them as a separate type.</div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 8, 2019 at 08:34 Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" rel="noreferrer" target="_blank">carter.schonwald@gmail.com</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"><div><div dir="auto">Thanks for eloquently summarizing , better than I would , what I thought I had laid out. </div></div><div dir="auto"><br></div><div dir="auto">Ieee floating point has fantastic hardware support . May as well be the first real language to actually use it correctly. :)</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Feb 8, 2019 at 5:21 AM Merijn Verstraaten <<a href="mailto:merijn@inconsistent.nl" rel="noreferrer" target="_blank">merijn@inconsistent.nl</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"><br>
<br>
> On 8 Feb 2019, at 10:57, Sven Panne <<a href="mailto:svenpanne@gmail.com" rel="noreferrer" target="_blank">svenpanne@gmail.com</a>> wrote:<br>
> <br>
> Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten <<a href="mailto:merijn@inconsistent.nl" rel="noreferrer" 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, 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
In other words, there are only two ways to get sane behaviour 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 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.<br>
<br>
Cheers,<br>
Merijn<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div></div>
_______________________________________________<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>
</blockquote></div></div>
</blockquote></div></div>