On Monday 16 June 2008, Evan Laforge wrote: > So, I know this has been discussed before, but: > > 1/0 > > Infinity > > > 0/0 > > NaN > > ... so I see from the archives that Infinity is mandated by ieee754 > even though my intuition says both should be NaN. > > Every other language throws an exception, even C will crash the > program, so I'm guessing it's telling the processor / OS to turn these > into signals, while GHC is turning that off. Or something. But then > what about this note in Control.Exception:
#include <stdio.h> #include <stdlib.h> int main (int argc, char **argv) { float f1 = 1.0/0.0; float f2 = 0.0/0.0; printf("%f\n%f\n", f1, f2); return EXIT_SUCCESS; } % ./Inf inf nan In a Haskell program, 1/0 is floating point division. In C, 1/0 is integer division, which may get implicitly converted to a floating point if you say "float f = 1/0;". That's why you get the exception in C. > but how about this: > > round (0/0) :: Integer > > (huge negative number) > > Ok, so integral types don't have that exceptional value. Shouldn't > trying to convert NaN or Infinity to an Integral throw something? Is > it a performance thing? I'd think if you're converting to Integer you > don't really need hardware level performance anyway, so a couple of > checks wouldn't kill anyone. This is a (known by some) bug of sorts in the various floating point -> integral transformations (which ultimately boil down to decodeFloat or something like that at some point). It apparently doesn't know about the various exceptional values in the IEEE representation, so it just treats the representation like any other value. Infinity and NaN look like various huge numbers if you interpret them like any other value, so that's what you get out of round/ceiling/floor/etc. It's not ideal, but I guess no one's bothered to fix it. Might be something to bring up on the libraries mailing list. -- Dan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe