<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Most of the arguments for making them rings feel kind of
pedantic, in any case. I can't think of a time I've ever used
actual ring theory to reason about Ints/Words. <br>
</p>
<div class="moz-cite-prefix">On 2/8/19 1:27 PM, Carter Schonwald
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHYVw0yKpE0K__OzO=+LcV_=RyL56U++6W4pLC-mYzHw1WqT5g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">david.feuer@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="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" moz-do-not-send="true">lennart@augustsson.net</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">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"
moz-do-not-send="true">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">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"
moz-do-not-send="true">merijn@inconsistent.nl</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"><br>
<br>
> On 8 Feb 2019, at 10:57, Sven Panne
<<a href="mailto:svenpanne@gmail.com"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">Libraries@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
rel="noreferrer noreferrer"
target="_blank" moz-do-not-send="true">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"
moz-do-not-send="true">Libraries@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">Libraries@haskell.org</a><br>
<a
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
</blockquote>
</body>
</html>