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:
http://svn.plt-scheme.org/plt/trunk/collects/tests/mzscheme/number.ss 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, Robby 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 > 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) > > > 359538626972463141629054847463408713596141135051689993197834953606314521560057077521179117265 > 533756343080917907028764928468642653778928365536935093407075033972099821153102564152490980180 > 778657888151737016910267884609166473806445896331617118664246696549595652408289446337476354361 > 838599762500808052368249716736 > > > > On Windows: > > > > Prelude> ceiling (0/0) > > - > 269653970229347386159395778618353710042696546841345985910145121736599013708251444699062715983 > 611304031680170819807090036488184653221624933739271145959211186566651840137298227914453329401 > 869141179179624428127508653257226023513694322210869665811240855745025766026879447359920868907 > 719574457253034494436336205824 > > > > 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 _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
