[Haskell] Re: Platform-dependent behaviour with functions on NaN

[Simon Marlow]

[ CC'ing glasgow-haskell-users at haskell.org ]

Geisler, Tim (EXT) wrote:
> In Haskell, the behaviour of functions on floating-point values which 
> are NaN can be platform dependent.
>  
> On "SunOS sun 5.9 Generic_118558-09 sun4u sparc SUNW,Sun-Blade-1500":
> Prelude> ceiling (0/0)
> 359538626972463141629054847463408713596141135051689993197834953606314521560057077521179117265533756343080917907028764928468642653778928365536935093407075033972099821153102564152490980180778657888151737016910267884609166473806445896331617118664246696549595652408289446337476354361838599762500808052368249716736
>  
> On Windows:
>  
> Prelude> ceiling (0/0)
> -269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824
>  
> Both machines use the binary distributions of GHC 6.4.1.

I assure you this isn't intentional.  In fact, I'm not sure why Sparc 
should be any different.  I don't have any Sparc machines to test on, 
and on all the platforms I have access to here I get a consistent answer 
(the same as the Windows answer you quoted above).

As far as I can tell, GHC is just using the Prelude definitions of the 
functions involved, there is no platform-specific code at the Haskell level.

What does 'decodeFloat (0/0)' return on your Sparc?

> There has been some discussion six years ago and nearly two years ago: 
> http://blog.gmane.org/gmane.comp.lang.haskell.glasgow.user/month=20040801
>  
> Is there a chance to
> - properly define the behaviour of functions depending on the function 
> properFraction for values like NaN, Infinity, ...?

This is a question for haskell-prime, to be answered by people who know 
more about floating point than I do...

> - get an implementation of this in GHC which computes the same results 
> for all platforms?

I would certainly hope so, if we can find the source of the discrepancy 
and devise a fix.

> Perhaps the function properFraction could raise an exception in case of 
> isNaN and isInfinity?

Sounds plausible.  Does anyone have any objections?

Cheers,
	Simon