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
359538626972463141629054847463408713596141135051689993197834953606314521560057077521179117265533756343080917907028764928468642653778928365536935093407075033972099821153102564152490980180778657888151737016910267884609166473806445896331617118664246696549595652408289446337476354361838599762500808052368249716736
On
Windows:
Prelude> ceiling
(0/0)
-269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907719574457253034494436336205824
-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@haskell.org http://www.haskell.org/mailman/listinfo/haskell
