John, >> Why is floating-point zero not zero?
> When it is the result of computational underflow. >> Should "(zero? 0.0)" be everything but true? Should "(zero? >> (exact->inexact 0))" be false? Should "(= 0.0 0.0)" be false? > No to all three questions. Then, I'm afraid, I can't follow your line of argument. This is surely an exceptional situation (the underflow), or not? libc's pow(3) does return 0.0 on underflow, therefore actually *not* indicating the error situation by return +NaN. What does IEEE say about this? >> Sure, numeric representation always meets a limit, but there must be >> some determinism, somewhere. > Agreed. The whole point of +inf.0, -inf.0, and +nan.0 is that they > provide determinism, unlike exceptions. The only difference between a special return-value and an exception is control flow. Neither is more or less deterministic, as long as the error-situation is detected. >> This is totally inconsistent. Even though the IEEE numeric model seems >> to be the de-facto standard I don't see why a high-level language >> should go out of its way just to follow this model because the >> number-crunchers like it? > The whole point of providing inexact numbers is to do number crunching. > I have spent a 30+ year career in programming without ever using flonums > in anger, except in languages like Basic, Perl, Lua, and JavaScript > where they are the only kind of number provided. Some people just use them to represent non-integral values. Like in graphics programming. Or financial stuff. Does that qualify as "number-crunching"? I don't think so. > But those who do want them, want IEEE behavior, not only simply because > it's a standard, but because it's a standard that actually provides > desirable behavior. How can you be so sure, especially since you already pointed out that you are not speaking from personal experience? Those that want IEEE behaviour (or whatever the machine provides) can use "fpexpt". But I think that Lisp-like languages and Scheme in particular always tried to impose some high-level view on numerical operations, like automatic overflow handling. Signalling an error on division by zero is for me just such a high-level situation, as would be signalling an error for leaving the domain of representable numbers in "expt". (expt -1 1.5) can not be represented in the value space of core chicken, so we have an exceptional situation. Since it can when "numbers" is used (the result seems to be incorrect but that's a different story...) returning +NaN in the former case would be an annoying inconsistency. Signalling an error appears to me more helpful and consistent with the manner Lisp systems approach the handling of violation of the language's semantics. (just pointing out the necessity of the full numeric tower in the core system is unnecessary and doesn't answer the question as such) cheers, felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
