Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report
Vanessa McHale
vanessa.mchale at iohk.io
Fri Feb 8 20:53:00 UTC 2019
Wouldn't both versions throw an exception in that case? Am I missing
something?
On 2/8/19 2:26 PM, David Feuer wrote:
> 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!
>
> On Fri, Feb 8, 2019, 3:05 PM Carter Schonwald
> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com> wrote:
>
> 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
>
> On Fri, Feb 8, 2019 at 3:03 PM Carter Schonwald
> <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>>
> wrote:
>
> No. A ring can’t have 2x=0 for x not zero. Thus int can’t be
>
> And by ring I mean an algebraic structure where you have a
> multiplicative group that doesn’t generate zero from products
> of nonzero elements ...
>
> 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.
>
> https://ghc.haskell.org/trac/ghc/ticket/8695 has some related
> discussions
>
>
> On Fri, Feb 8, 2019 at 2:53 PM Jens Blanck
> <jens.blanck at gmail.com <mailto:jens.blanck at gmail.com>> wrote:
>
> > minBound + minBound :: Int
> 0
> > negate minBound == (minBound :: Int)
> True
> > 42 + negate 17 :: Word
> 25
>
> 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.
>
> I'd be very happy to see a separate type for signalling
> integral types. Personally, I'd make them the default choice.
>
> On Fri, 8 Feb 2019 at 19:27, Carter Schonwald
> <carter.schonwald at gmail.com
> <mailto:carter.schonwald at gmail.com>> wrote:
>
> 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.
>
> Simple example where all the finite signed ints work
> wrong today :
>
> There’s no proper additive inverse for minBound :: int
>
> Likewise , what’s our current definition of negate on
> finite word types?
>
> On Fri, Feb 8, 2019 at 2:12 PM David Feuer
> <david.feuer at gmail.com <mailto:david.feuer at gmail.com>>
> wrote:
>
> 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!
>
> On Fri, Feb 8, 2019, 2:07 PM Lennart Augustsson
> <lennart at augustsson.net
> <mailto:lennart at augustsson.net> 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
> <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 <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
--
*Vanessa McHale*
Functional Compiler Engineer | Chicago, IL
Website: www.iohk.io <http://iohk.io>
Twitter: @vamchale
PGP Key ID: 4209B7B5
Input Output <http://iohk.io>
Twitter <https://twitter.com/InputOutputHK> Github
<https://github.com/input-output-hk> LinkedIn
<https://www.linkedin.com/company/input-output-global>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190208/f0a0fbfe/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190208/f0a0fbfe/attachment.sig>
More information about the Libraries
mailing list