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.
 
In our production code, this error (which is actually an error in our program) occured inside a quite complex expression which can be simplified to max 0 (ceiling (0/0)).  On Windows, we did not recognize the error in the program, because the complex expression just returned 0.  On Solaris, the complex expression returned this large number (which represents in the application "the number of CPUs needed in a certain device" ;-)
 
We develop Haskell programs on Windows and run them in production on Sparc with Solaris. It seems that we have to run special regression tests testing for differences between Sparc Solaris and Windows.
 
The Haskell 98 report http://www.haskell.org/onlinereport/basic.html#sect6.4 states: "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."
 
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, ...?
- get an implementation of this in GHC which computes the same results for all platforms?
 
Perhaps the function properFraction could raise an exception in case of isNaN and isInfinity?
 
Other languages are more portable. E.g., for Java, these cases are defined. http://java.sun.com/docs/books/jls/second_edition/html/typesValues.doc.html#9249 states: "All numeric operations with NaN as an operand produce NaN as a result."
 
Tim