> Any time the same value comes into the computation more than
> once, it should be the SAME error in the same direction.
Understood. Is there any sort of consensus about good techniques in
this area? (Affine arithmetic, etc.)
> > Ideally, we'd rework Maxima so that it generalizes its
> > notion of number to include not just integers, rats, and
> > bigfloats, but also complexes, intervals, etc. Not trivial, but....
> Some of these require no more than using the underlying Lisp numbers.
The problem is not in implementing the operations, it is in getting
Maxima to use them appropriately, and to treat these objects sensibly.
Right now, most parts of Maxima handle the closed set of known numeric
types (integer, float, RAT, bigfloat) ad hoc. That is, there is no
information hiding, so it is very painful to add a new numeric type.
There are known places which don't do it right. (A major one: the RAT
package doesn't support bigfloat coefficients.)
Assumptions are made about the properties of numbers. For example:
Everything that is numberp is assumed real (unlike #C(1.23 -2.45)).
Every number that is not integer or RAT is assumed approximate (not #C(2
1) or 23/47 or #C(1/2 2/3) or finite continued fractions). Trichotomy
is assumed to apply to all numbers (not true of intervals, complexes,
and IEEE floats with NaNs). Numbers are assumed finite (not true of
IEEE floats with NaNs and infinities, for projective numbers, and
nonstandard numbers (infinitesimals etc.)). And so on.
I don't think it's possible to make all of Maxima work with all these
kinds of numbers everywhere -- there are too many basic *mathematical*
assumptions in too many places, trichotomy for example. But it might
well be time to go through Maxima systematically and generalize the
number system -- while of course preserving efficiency!
-s