Dear David, et al: I can't comment upon James Anderson's work, but I do want to respond to your comment re programming & dealing with exceptional cases such as division by zero. I agree with you, more-or-less, that exceptions have to get handled in some form, and there is no sweeping them under the rug, but mathematics has improved things for programmers immensely with their inventions which reduce the number of exceptional cases that have to be handled -- or at least move the handling of these cases to more convenient places in the program. The invention of zero, and especially negative numbers, eliminated a whole class of "exceptions" that would otherwise have to be handled. The complexity of the beginning programmer's attempt at a quadratic equation solver is reduced significantly in programming languages having complex number datatypes. The complexity of graphics programming was dramatically reduced with the introduction of "homogeneous" coordinate systems which put off the final division (which could raise an exception) until the very end of the process. The history of "exceptions" in computer hardware is one of the most painful and ugly stories ever told. With every advance in computer speed, the cost of an exception grows (relative to "normal" execution). The ability to deal with exceptional situations up front -- prior to going into a long pipeline -- or at the end -- after the data comes out of a long pipeline -- is extremely important, and any help mathematicians can provide in managing exceptions will be welcomed. Computer hardware people often don't consult mathematicians before trying new things, so there are many efforts that they have made which are probably painful and/or laughable to the mathematician. Rather than hold such attempts up to ridicule, however, mathematicians should provide more inspiration in the form of elegant solutions for these problems. At 09:35 PM 12/13/2006, David Wilson wrote:

In everyday programming, when you run into division by zero, it generally indicates an error condition or special case to be handled. However you detect the division by zero, you still have to deal with the condition that brought it about. Whether you say

// Defensive programming if (b == 0) { c = a/b; } else { doSomethingSpecial(); }

or

// Exception handling try { c = a/b; } catch (DivideByZeroException) { doSomethingSpecial(); }

or

// Special value detection c = a/b; if (c == infinity or c == -infinity or c == nullity) { doSomethingSpecial(); }

you are still required to detect the division by zero and invoke doSomethingSpecial() to handle it, otherwise your program fails. Transreal arithmetic does not alleviate you of the burden of properly handling arithmetic exceptions, it merely changes the syntax and knowledge required to detect them. Which is better, to detect problems when they happen and possibly fail, or let your program continue using meaningless values?

Ultimately, failure to detect and handle arithmetic exceptions simply shifts the problem to another place in the program. If

c = a/b;

sustains an undetected division by zero and gets set to -infinity or infinity or nullity, what happens later on down the line when you try to execute

x = array[c];

At some point, you have to detect the problem, and from a debugging standpoint, better sooner than later.