Dan Bron <[EMAIL PROTECTED]> wrote: > RM = Raul Miller, DB = me
> RM> infinite digits are required. > DB> Required for what application? > RM> Complete accuracy in all contexts. > This is precisely the cop out to avoid. Define your contexts. Decide how many > digits is enough. Saying "I need infinite precision because that way I can be > confident that my result is correct no matter how I obtain it" is precisely > equivalent to saying "I give up". > If you don't know how many digits you need, or how to obtain them, don't expect > that the J interpreter or the IEEE council will. The best you can hope for is > that they'll provide many more than you require (i.e. an approximation of > infinity). If that turns out not to be the case, you've got some decisions to make > and some debts to pay. The discussion of this topic seems to me to lack focus. Or maybe I can't see the real problem. But I think the issues are very important. The first area is representation. There are many ways to represent numerical values. But the real issue, and this comes with whatever problem is being considered, is whether to represent the value exactly or not. The value one third can be represented exactly in duodecimal representation. A multiple of pi can be represented exactly if a field in the representation is provided for n of "times pi to the power n". Digital computers usually provide two distinct, limited and unfortunately separate classes of representation, exact (or integer) and inexact (or floating point). The J interpreter, thank goodness, takes the lid off the exact and supplements it with rational (and complex - hurrah !) The second area is arithmetic. Digital computers usually separate exact arithmetic, restricted to integer representation, and inexact arithmetic, restricted to floating point representation. The J interpreter, bless it, provides for smooth transition from exact to inexact, and provides for its nature to be tested. Now exact arithmetic, as provided by J, is completely accurate because an exact result can be represented to any precision. But the accuracy of inexact arithmetic depends more on the computation than it does on the precision of the representation used. Doubling the precision might or might not improve the accuracy; when trillions of additions and multiplications are carried out in a large computation, and each of these operations carries its own truncation error, the accuracy goes down. The beauty of J is that its exact arithmetic can often be used to preserve exactness of a result. Exactness yields certainty, provided the starting data are exact and the algorithm is exact. And certainty is an ideal to be striven for. Unfortunately, starting data are often inexact, or cannot be represented exactly, which comes to the same thing. It's interesting, though little known, that inexact computation can yield certainty in its results. This is done by a sophisticated use of interval arithmetic, and, to be more practical, supplemented by exact scalar product arithmetic. Best known in Europe where it's called "validated numerics" among other things, this can be tracked down through http://www.math.uu.se/~warwick/tmp/ecm04.pdf though it seems to be better deployed in Germany. In general terms the technique uses algorithms in such a way that if the solution converges under iteration then this is mathematical proof that the solution is within the intervals of the result. The sophistication is in designing the algorithms so that such convergance is almost always obtained. And possible improvement in accuracy can be obtained by continuing the iteration. The problem is that, to be popular and competitive, validated numerics needs particular hardware support, for example for directed rounding. Although directed rounding was specified in the IEEE standard, its implementation is extremely poor. Unfortunately the present revision committee seems unconviced that certainty in computation has any particular value, so the revised standard is probably going to be little better than the old one in this respect. Nevertheless, it would be good if the J interpreter would eventually support modern interval arithmetic. This would certainly be appreciated in many mathematical circles in Europe. Neville Holmes, P.O.Box 404, Mowbray 7248, Tasmania Normal e-mail: [EMAIL PROTECTED] Send instant messages to your online friends http://au.messenger.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
