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