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) 359538626972463141629054847463408713596141135051689993197834953606314521 560057077521179117265533756343080917907028764928468642653778928365536935 093407075033972099821153102564152490980180778657888151737016910267884609 166473806445896331617118664246696549595652408289446337476354361838599762 500808052368249716736 On Windows: Prelude> ceiling (0/0) -26965397022934738615939577861835371004269654684134598591014512173659901 370825144469906271598361130403168017081980709003648818465322162493373927 114595921118656665184013729822791445332940186914117917962442812750865325 722602351369432221086966581124085574502576602687944735992086890771957445 7253034494436336205824 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=2004080 1 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.h tml#9249 states: "All numeric operations with NaN as an operand produce NaN as a result." Tim