> 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.
Actually, symbolic computations can be done as
yet another datatype and the only cost ("sacrifice")
would be implementation effort that could be
expended in other areas. You can look at f&.g and
f b. _1 for indications of what can be done with
symbolics in J.
----- Original Message -----
From: John Randall <[EMAIL PROTECTED]>
Date: Thursday, December 7, 2006 7:01 pm
Subject: Re: [Jgeneral] exp(y). sin(y) and accuracy.
> 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.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
