[Haskell] Platform-dependent behaviour with functions on NaN

[Geisler, Tim (EXT)]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/haskell/attachments/20060413/6b5177b7/attachment.htm