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