[ 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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
