Proposal: New Eq and Ord instances for Double and Float

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

Re: Proposal: New Eq and Ord instances for Double and Float

Malcolm Wallace-2
>>> Proposal: Provide Double and Float with Eq and Ord instances that introduce
>>> a total order.

Some implementations of Haskell *already* provide a total ordering for the Float type, and this is perfectly allowed within the definition of the 2010 Language Report.

To quote Section 6.4:

"Float is implementation-defined; it is desirable that this type be at least equal in range and precision to the IEEE single-precision type. [...]  The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types are undefined; an implementation may choose error (⊥, semantically), a truncated value, or a special value such as infinity, indefinite, etc."

If any program intends to rely on the IEEE behaviour for exceptional conditions, then for correctness, it really ought to use the RealFloat class method "isIEEE" to be certain that the compiler implementation actually supports that.

Regards,
    Malcolm




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

Re: Proposal: New Eq and Ord instances for Double and Float

Simon Marlow-7
In reply to this post by Roman Leshchinskiy
On 27/09/2011 10:02, Roman Leshchinskiy wrote:

> Colin Paul Adams wrote:
>>
>> A quick google for signalling NaNs seems to suggest that on the x86
>> architecture, you have to set a flag to raise an exception when
>> encountering signalling NaNs. Otherwise they are just treated as quiet
>> NaNs.
>> But you have to create the signalling NaNs manually. They are not
>> created as a result of arithmetic operations.
>
> IIRC, with the appropriate flags set, arithmetic operations throw
> exceptions instead of creating NaNs. You can't really create a signalling
> NaN in a register because as soon as you do, you get a signal.

But they don't throw a Haskell exception, they throw a processor
exception which kills your whole program.  If we want a Haskell
exception to result from 0/0, we have to insert extra checking code,
which I'm sure you won't like :-)

Cheers,
        Simon


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

Re: Proposal: New Eq and Ord instances for Double and Float

Roman Leshchinskiy
Simon Marlow wrote:

> On 27/09/2011 10:02, Roman Leshchinskiy wrote:
>> Colin Paul Adams wrote:
>>>
>>> A quick google for signalling NaNs seems to suggest that on the x86
>>> architecture, you have to set a flag to raise an exception when
>>> encountering signalling NaNs. Otherwise they are just treated as quiet
>>> NaNs.
>>> But you have to create the signalling NaNs manually. They are not
>>> created as a result of arithmetic operations.
>>
>> IIRC, with the appropriate flags set, arithmetic operations throw
>> exceptions instead of creating NaNs. You can't really create a
>> signalling
>> NaN in a register because as soon as you do, you get a signal.
>
> But they don't throw a Haskell exception, they throw a processor
> exception which kills your whole program.  If we want a Haskell
> exception to result from 0/0, we have to insert extra checking code,
> which I'm sure you won't like :-)

I would, of course, expect the RTS to convert the processor exception to a
Haskell exception!

Roman




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

Re: Proposal: New Eq and Ord instances for Double and Float

Simon Marlow-7
On 10/11/2011 16:28, Roman Leshchinskiy wrote:

> Simon Marlow wrote:
>> On 27/09/2011 10:02, Roman Leshchinskiy wrote:
>>> Colin Paul Adams wrote:
>>>>
>>>> A quick google for signalling NaNs seems to suggest that on the x86
>>>> architecture, you have to set a flag to raise an exception when
>>>> encountering signalling NaNs. Otherwise they are just treated as quiet
>>>> NaNs.
>>>> But you have to create the signalling NaNs manually. They are not
>>>> created as a result of arithmetic operations.
>>>
>>> IIRC, with the appropriate flags set, arithmetic operations throw
>>> exceptions instead of creating NaNs. You can't really create a
>>> signalling
>>> NaN in a register because as soon as you do, you get a signal.
>>
>> But they don't throw a Haskell exception, they throw a processor
>> exception which kills your whole program.  If we want a Haskell
>> exception to result from 0/0, we have to insert extra checking code,
>> which I'm sure you won't like :-)
>
> I would, of course, expect the RTS to convert the processor exception to a
> Haskell exception!

You have high expectations :-)  I don't think it's possible to do that
without some very low-level platform-specific and processor-specific
hacking, which is why for example we have the current software test for
divide-by-zero.  You basically get a signal and have to grovel around in
the thread's registers and stack to recover the situation, and the
exception could be thrown from *anywhere*.

Cheers,
        Simon

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

Re: Proposal: New Eq and Ord instances for Double and Float

Roman Leshchinskiy
Simon Marlow wrote:

> On 10/11/2011 16:28, Roman Leshchinskiy wrote:
>> Simon Marlow wrote:
>>> On 27/09/2011 10:02, Roman Leshchinskiy wrote:
>>>> Colin Paul Adams wrote:
>>>>>
>>>>> A quick google for signalling NaNs seems to suggest that on the x86
>>>>> architecture, you have to set a flag to raise an exception when
>>>>> encountering signalling NaNs. Otherwise they are just treated as
>>>>> quiet
>>>>> NaNs.
>>>>> But you have to create the signalling NaNs manually. They are not
>>>>> created as a result of arithmetic operations.
>>>>
>>>> IIRC, with the appropriate flags set, arithmetic operations throw
>>>> exceptions instead of creating NaNs. You can't really create a
>>>> signalling
>>>> NaN in a register because as soon as you do, you get a signal.
>>>
>>> But they don't throw a Haskell exception, they throw a processor
>>> exception which kills your whole program.  If we want a Haskell
>>> exception to result from 0/0, we have to insert extra checking code,
>>> which I'm sure you won't like :-)
>>
>> I would, of course, expect the RTS to convert the processor exception to
>> a
>> Haskell exception!
>
> You have high expectations :-)  I don't think it's possible to do that
> without some very low-level platform-specific and processor-specific
> hacking, which is why for example we have the current software test for
> divide-by-zero.  You basically get a signal and have to grovel around in
> the thread's registers and stack to recover the situation, and the
> exception could be thrown from *anywhere*.

Oh, I never said it would be easy :-) But this definitely seems like the
right thing to do to me.

In the context of this thread, however, it would be perfectly acceptable
if NaNs just aborted the program. The original problem was that they mess
up things. It is implementation-defined what happens if a computation
wants to create a NaN. We could simply say that the program is aborted by
default, with a way to turn off this behaviour and just create a NaN.
Raising a Haskell exception would certainly be very nice but not essential
for this particular problem.

Roman




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

Re: Proposal: New Eq and Ord instances for Double and Float

Twan van Laarhoven
On 10/11/11 18:03, Roman Leshchinskiy wrote:

> Oh, I never said it would be easy :-) But this definitely seems like the
> right thing to do to me.
>
> In the context of this thread, however, it would be perfectly acceptable
> if NaNs just aborted the program. The original problem was that they mess
> up things. It is implementation-defined what happens if a computation
> wants to create a NaN. We could simply say that the program is aborted by
> default, with a way to turn off this behaviour and just create a NaN.
> Raising a Haskell exception would certainly be very nice but not essential
> for this particular problem.

That seems dangerous. This is what happens now if I use unchecked div
for example:

     $ ghci
     Prelude> GHC.Base.divInt 1 0
     Floating point exception
     $

It exits ghci immediately. Having "0/0" crash would make trusting 'safe'
programs much harder. For example, I could no longer make an IRC bot for
evaluating numeric expressions, and expect it to keep running.


Twan

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

Re: Proposal: New Eq and Ord instances for Double and Float

Roman Leshchinskiy
Twan van Laarhoven wrote:

> On 10/11/11 18:03, Roman Leshchinskiy wrote:
>> Oh, I never said it would be easy :-) But this definitely seems like the
>> right thing to do to me.
>>
>> In the context of this thread, however, it would be perfectly acceptable
>> if NaNs just aborted the program. The original problem was that they
>> mess
>> up things. It is implementation-defined what happens if a computation
>> wants to create a NaN. We could simply say that the program is aborted
>> by
>> default, with a way to turn off this behaviour and just create a NaN.
>> Raising a Haskell exception would certainly be very nice but not
>> essential
>> for this particular problem.
>
> That seems dangerous. This is what happens now if I use unchecked div
> for example:
>
>      $ ghci
>      Prelude> GHC.Base.divInt 1 0
>      Floating point exception
>      $

One could argue that this is a bug in ghci - perhaps it shouldn't abort if
evaluating an expression causes an error.

> It exits ghci immediately. Having "0/0" crash would make trusting 'safe'
> programs much harder. For example, I could no longer make an IRC bot for
> evaluating numeric expressions, and expect it to keep running.

You could by explicitly enabling silent NaNs and handling them specially.
The original problem was that we currently silently generates NaNs which
have surprising semantics if you aren't specifically dealing with them.
This problem is solved by having NaNs abort the program and having a way
to recover the current behaviour.

Again, having a Haskell exception would be vastly preferable but as a
short-term solution, aborting the program seems acceptable to me.

Roman




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

Re: Proposal: New Eq and Ord instances for Double and Float

Simon Marlow-7
On 11/11/2011 14:02, Roman Leshchinskiy wrote:

> Twan van Laarhoven wrote:
>> On 10/11/11 18:03, Roman Leshchinskiy wrote:
>>> Oh, I never said it would be easy :-) But this definitely seems like the
>>> right thing to do to me.
>>>
>>> In the context of this thread, however, it would be perfectly acceptable
>>> if NaNs just aborted the program. The original problem was that they
>>> mess
>>> up things. It is implementation-defined what happens if a computation
>>> wants to create a NaN. We could simply say that the program is aborted
>>> by
>>> default, with a way to turn off this behaviour and just create a NaN.
>>> Raising a Haskell exception would certainly be very nice but not
>>> essential
>>> for this particular problem.
>>
>> That seems dangerous. This is what happens now if I use unchecked div
>> for example:
>>
>>       $ ghci
>>       Prelude>  GHC.Base.divInt 1 0
>>       Floating point exception
>>       $
>
> One could argue that this is a bug in ghci - perhaps it shouldn't abort if
> evaluating an expression causes an error.

GHC.Base.divInt is an unsafe function, in the same way that unsafeCoerce
is: you can crash the program by using it in the wrong way.  Maybe it
should be called unsafeDivInt, but this isn't a user-visible API, so we
don't really care.

>> It exits ghci immediately. Having "0/0" crash would make trusting 'safe'
>> programs much harder. For example, I could no longer make an IRC bot for
>> evaluating numeric expressions, and expect it to keep running.
>
> You could by explicitly enabling silent NaNs and handling them specially.
> The original problem was that we currently silently generates NaNs which
> have surprising semantics if you aren't specifically dealing with them.
> This problem is solved by having NaNs abort the program and having a way
> to recover the current behaviour.
>
> Again, having a Haskell exception would be vastly preferable but as a
> short-term solution, aborting the program seems acceptable to me.

I'm surprised to hear you say that - aborting the program is *never*
acceptable behaviour as far as I'm concerned, unless the API is
explicitly labelled "unsafe" and you use it in an unsafe way.  Even the
rare places in Haskell where behaviour is explicitly undefined never
abort the program in GHC.

It would be a shame if any module using division were not allowed to be
classed as "safe" by SafeHaskell.

Cheers,
        Simon

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

Re: Proposal: New Eq and Ord instances for Double and Float

Tyson Whitehead
In reply to this post by Simon Marlow-7
On November 10, 2011 11:48:33 Simon Marlow wrote:

> On 10/11/2011 16:28, Roman Leshchinskiy wrote:
> > I would, of course, expect the RTS to convert the processor exception to
> > a Haskell exception!
>
> You have high expectations :-)  I don't think it's possible to do that
> without some very low-level platform-specific and processor-specific
> hacking, which is why for example we have the current software test for
> divide-by-zero.  You basically get a signal and have to grovel around in
> the thread's registers and stack to recover the situation, and the
> exception could be thrown from *anywhere*.

Historically some processors have also made these exceptions imprecise as
faster execution can be produced by not having the pipeline be constrained by
the requirement to roll earlier stage effects back if an exception is raised.

http://books.google.ca/books?id=GumAeql5KPkC&pg=SA4-PA69&lpg=SA4-
PA69&dq=alpha+imprecise+traps

While software barriers can be inserted to make it possible to pin exceptions
down to greater degrees (see -mtrap-precision), it costs you performance.

http://gcc.gnu.org/onlinedocs/gcc/DEC-Alpha-Options.html

Cheers!  -Tyson

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12