On Nov 19, 1:10 pm, samppi <[EMAIL PROTECTED]> wrote: > I am not familiar with how Java's arithmetic works, but it seems > fromhttp://hanuska.blogspot.com/2007/08/arithmeticexception-vs-nan.html > andhttp://www.concentric.net/~Ttwang/tech/javafloat.htmthat dividing > a double or float by 0 should result in positive or negative infinity > (like Double.POSITIVE_INFINITY) or NaN (e.g. Double.NaN). But doing so > in Clojure always throws an ArithmeticException. Is this different > from Java's behavior? Is it possible to get positive or negative > infinity from division in Clojure?
I can't speak from Rich but I've noticed this behavior in other Lisp implementations (like SBCL) that are built on C. The Lisp implementation changes the semantics of floating-point divide-by- zero. (The ANSI Common Lisp standard defines the DIVISION-BY-ZERO condition -- see http://www.lispworks.com/documentation/HyperSpec/Body/e_divisi.htm#division-by-zero -- but I can't tell whether it _requires_ that floating-point 1.0/0.0, for example, signal a condition or just return Inf.) There are good reasons for not signaling division by zero in floating- point arithmetic; some eigenvalue computations, for example, can be made much faster if they don't have to check for such exceptions (and if the hardware floating-point implementation doesn't trap them and handle them in software). There are also good reasons _to_ signal division by zero ;-) I have the sense that users of various Lisps don't mind handling such conditions interactively because Lisp environments tend to support interactive debugging and code modification. The ANSI Common Lisp condition system lets programmers handle such things systematically (by defining the appropriate restart), at the cost of more complexity for the Lisp implementer ;-) The try-catch-finally system that Clojure inherits from Java doesn't let you return to the "try" block if you divide by zero, but you can do the following: * Provide two implementations of a function f: 1. f1: Doesn't test for exceptional arithmetic conditions like division by zero, so the code is cleaner and probably much faster (since there are fewer branches). Also must not have irreversible side effects. 2. f2: Does test for exceptional arithmetic conditions (not indiscriminately -- only at places where you don't want them to signal), and replaces them with their appropriate values like Double.POSITIVE_INFINITY or Double.NaN. I'm guessing (though I'm not sure, as I haven't tried it) that computations with such values will also throw exceptions in Clojure, so you'll have to think about what happens when such values propagate through your computation. Usually you can isolate the places where you _know_ yo might get Inf (for example) and where you _know_ you want to let it propagate. Resist the temptation to check everything! * Wrap f1 in a try block, and if you catch one of the exceptional arithmetic conditions that you want to ignore, undo any side effects of f1, and call f2. The common case should be faster because you can save a lot of branches. It should also have a smaller chance of having bugs because it's very hard to test for just the conditions that you care about. mfh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
