Add Ord Laws to next Haskell Report

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

David Feuer
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 <[hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> 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 <[hidden email]> wrote:


> On 8 Feb 2019, at 10:57, Sven Panne <[hidden email]> wrote:
>
> Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten <[hidden email]>:
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

Vanessa McHale

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 <[hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> 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 <[hidden email]> wrote:


> On 8 Feb 2019, at 10:57, Sven Panne <[hidden email]> wrote:
>
> Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten <[hidden email]>:
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
--



Vanessa McHale
Functional Compiler Engineer | Chicago, IL

Website: www.iohk.io
Twitter: @vamchale
PGP Key ID: 4209B7B5

Input
          Output

Twitter Github LinkedIn


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

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

Bardur Arantsson-2
On 08/02/2019 21.53, Vanessa McHale wrote:
> Wouldn't both versions throw an exception in that case? Am I missing
> something?

Not necessarily, the classic example would be the Binary Search bug


https://thebittheories.com/the-curious-case-of-binary-search-the-famous-bug-that-remained-undetected-for-20-years-973e89fc212

(it could be argued that you really want a *trap* in this case as it
would surface the bug, but I'm just confirming that there *can* be
different behavior.)

Generally: I think it's fine to expect WordNN to do wrap-around
arithmetic (and it does form a proper ring), but IntNN is kind of weird
because there is that edge case[1] of minBound (as Carter mentioned
ITT). IME, usually Word-like types are used for things like crypto, etc.
-- not just when you want to enforce "not negative", but that may just
be my little bubble.

[1] In two's complement which even C++20 is set to mandate!

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

Bardur Arantsson-2
In reply to this post by Lennart Augustsson
On 08/02/2019 20.07, Lennart Augustsson wrote:
> I would *hate* to lose quiet NaNs.

This is just getting further off-topic. Nobody is suggesting this, AFACIT.

+1 to the original suggestion to just specify totality for Ord (how
could it *not* be?) and mention that Double/Float instances are not
currently lawful.

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

Haskell - Libraries mailing list
In reply to this post by Carter Schonwald

Please delete me. Thank you




On Friday, February 8, 2019 Vanessa McHale <[hidden email]> wrote:

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.

On 2/8/19 1:27 PM, Carter Schonwald 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 <[hidden email]> 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 <[hidden email] 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 <[hidden email]> 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 <[hidden email]> wrote:


> On 8 Feb 2019, at 10:57, Sven Panne <[hidden email]> wrote:
>
> Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten <[hidden email]>:
> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

Ganesh Sittampalam
In reply to this post by Lennart Augustsson
Wouldn't having both quiet and signalling NaN types imply wrapping all
the primitive operations for one or other type in a CPU state switch?
Maybe the compiler could then optimise some away.

On 08/02/2019 19:07, Lennart Augustsson 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
> <[hidden email] <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>
>         > On 8 Feb 2019, at 10:57, Sven Panne <[hidden email]
>         <mailto:[hidden email]>> wrote:
>         >
>         > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten
>         <[hidden email] <mailto:[hidden email]>>:
>         > 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
>         [hidden email] <mailto:[hidden email]>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Floats, the true ieee next generation Re: Add Ord Laws to next Haskell Report

Carter Schonwald
Hey Ganesh,
because of how float stuff works, the code generated will be the same either way.

On Sun, Feb 10, 2019 at 4:17 PM Ganesh Sittampalam <[hidden email]> wrote:
Wouldn't having both quiet and signalling NaN types imply wrapping all
the primitive operations for one or other type in a CPU state switch?
Maybe the compiler could then optimise some away.

On 08/02/2019 19:07, Lennart Augustsson 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
> <[hidden email] <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>
>         > On 8 Feb 2019, at 10:57, Sven Panne <[hidden email]
>         <mailto:[hidden email]>> wrote:
>         >
>         > Am Do., 7. Feb. 2019 um 23:31 Uhr schrieb Merijn Verstraaten
>         <[hidden email] <mailto:[hidden email]>>:
>         > 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
>         [hidden email] <mailto:[hidden email]>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>     _______________________________________________
>     Libraries mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
123