I agree with Ralph that a demand for unreasonable (and probably spurious) floating-point accuracy is unwarranted. Small inaccuracies do not cause significant problems in most real-world applications. If they did, we would be stuck at the beginning, when we represent uncountably many real numbers by finitely many rational numbers.
I find there is a fair amount of ignorance about floating-point issues even among people who are otherwise computer-savvy. Part of this is justified: almost all computer programs never use floating-point arithmetic, except casually, and floating-point hardware used to be an optional extra until very recently. (Texas Instruments calculators still chug along on the Z80, which does not even have a hardware multiply, let alone any floating-point hardware.) Designing a floating-point library that is fast and reasonably accurage over a wide range of arguments is highly non-trivial. As Ralph has mentioned, you either take what you are given, or use a more accurate library and pay a run-time penalty. You may also wish to rephrase your problem so that the inaccuracies do not matter as much. For example, the LAPACK library functions spend a lot of effort on factorizing and rescaling matrices so that the effects of ill-conditioning and roundoff error are minimized. The idea of "using exact values when you can recognize them", as in evaluating sin(pi), is only peripherally related to floating-point issues. You have to recognize pi before you have evaluated it to a floating-point number: after that, you cannot tell it is "supposed" to be pi. Symbolic languages deal with this issue, but incur significant overhead in all calculations. It is a price not worth paying if you just want sin(pi) to be "correct": it may be worth paying if you want to symbolically solve partial differential equations. Personally, I think that adding multiple-precision calculations to J is harmless and possibly useful idea. Roger's description suggested that to the user it would appear as just another data type, although I imagine it would be a lot of work at his end. Moving in the direction of symbolic computation might mean sacrificing some of J's strengths for an uncertain gain. Best wishes, John ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
