[Haskell] Platform-dependent behaviour with functions on NaN
robby at cs.uchicago.edu
Fri Apr 14 11:19:10 EDT 2006
I don't know if it would help, but PLT Scheme has been thru this and
Matthew Flatt has a nice test suite that you can see here:
To help read the code, when you see something like:
(test a b c ...)
that is the same thing as applying the operator "b" to the arguments "c
..." and then comparing the result to "a" (and expecting it to match).
A variation (defined in this file) is test-nan.0 that takes the "b" and
"c"s above, and passes not-a-number along as the expected result.
Sure enough, the bug below would have been caught by the test suite,
because it contains:
(test-nan.0 ceiling +nan.0)
One could probably automate a translation of the test suite to
Quickcheck with some Emacs macros or (god forbid!) a Scheme program. :)
Anyways, if you do want to use those test cases, I'm happy to explain
any Schemeisms you find in there.
Just a Schemer's $0.02,
At Fri, 14 Apr 2006 10:04:51 -0400, Lennart Augustsson wrote:
> 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
> 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)
> > On Windows:
> > Prelude> ceiling (0/0)
> > -
> > 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
> Haskell mailing list
> Haskell at haskell.org
More information about the Haskell