[ CC'ing glasgow-haskell-users@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