<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Wouldn't both versions throw an exception in that case? Am I
missing something?<br>
<span></span></p>
<div class="moz-cite-prefix">On 2/8/19 2:26 PM, David Feuer wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMgWh9uh2g4oHtZXBCGhRWpax-F31E9dOMk=HV2jCeRtvOU0LQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Yes, but a ring is sufficient for lots of very
basic and important manipulations. When I'm writing code with
Int and Word, I don't even think about whether the associative
and distributive laws apply--I just use them to simplify my
definitions. With trapping overflow, I need to watch for ranges
every time I apply one. Horrible!</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Feb 8, 2019, 3:05 PM Carter Schonwald
<<a href="mailto:carter.schonwald@gmail.com"
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">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"
target="_blank" rel="noreferrer"
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">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" rel="noreferrer"
moz-do-not-send="true">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" rel="noreferrer"
moz-do-not-send="true">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" rel="noreferrer"
moz-do-not-send="true">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" rel="noreferrer"
moz-do-not-send="true">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" rel="noreferrer"
moz-do-not-send="true">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 noreferrer"
target="_blank"
moz-do-not-send="true">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 noreferrer"
target="_blank"
moz-do-not-send="true">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 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
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
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 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 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
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 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
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>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org"
target="_blank" rel="noreferrer"
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>
</blockquote>
</div>
</div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank"
rel="noreferrer" 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>
<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>
<div class="moz-signature">-- <br>
<br>
<br>
<br>
<strong
style="color:#000;font-family:Helvetica,Arial;font-size:116%;">Vanessa
McHale</strong><br>
<span
style="color:#000;font-family:Helvetica,Arial;font-size:100%;"><span
style="color:#f00">Functional Compiler Engineer |</span>
Chicago, IL</span>
<br>
<br>
<span
style="color:#999;font-family:Helvetica,Arial;font-size:85%;">Website:
<a href="http://iohk.io" style="color:#f00;">www.iohk.io</a></span><br>
<span
style="color:#999;font-family:Helvetica,Arial;font-size:85%;">Twitter:
@vamchale</span><br>
<span
style="color:#999;font-family:Helvetica,Arial;font-size:85%;">PGP
Key ID: 4209B7B5</span><br>
<br>
<a href="http://iohk.io"><img
src="https://static.iohk.io/logo/logo-email.png" alt="Input
Output" width="200" height="46"></a>
<br>
<br>
<a href="https://twitter.com/InputOutputHK"><img
src="https://static.iohk.io/images/ic-tw.png" alt="Twitter"
width="18" height="16"></a>
<a href="https://github.com/input-output-hk"><img
src="https://static.iohk.io/images/ic-gh.png" alt="Github"
width="21" height="16"></a>
<a href="https://www.linkedin.com/company/input-output-global"><img
src="https://static.iohk.io/images/ic-li.png" alt="LinkedIn"
width="19" height="16"></a>
<br>
<br>
<br>
<span
style="color:#444;font-family:Helvetica,Arial;font-size:77%;"><small>This
e-mail and any file transmitted with it are confidential and
intended solely for the use of the recipient(s) to whom it is
addressed. Dissemination, distribution, and/or copying of the
transmission by anyone other than the intended recipient(s) is
prohibited. If you have received this transmission in error
please notify IOHK immediately and delete it from your system.
E-mail transmissions cannot be guaranteed to be secure or
error free. We do not accept liability for any loss, damage,
or error arising from this transmission</small></span></div>
</body>
</html>