[Haskell] Platform-dependent behaviour with functions on NaN

[Lennart Augustsson]

Yeah, I think it boils down to different representations of NaN on
different platform.  I guess I forgot to test for NaN when I wrote
(the C code for) decodeFloat.  It should generate some consistent
result.
On the other hand, if you have code that possible divides by 0
and don't check for it, well...
It would be nice if Haskell allowed you to turn on signalling NaNs.

	-- Lennart

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