For a start, do you want the interval analysis to be
done only
when you compile a function, (CMU-CL) or each time you
do an operation, e.g. add, multiply, or perhaps
run an
iteration to try to converge to an answer. (in
principle what
Mathematica would do, or Maple;s range arithmetic).
This is not so difficult in the context of extending
(say) Fortran.
Just tedious.
In the context of symbolic systems, it become more
difficult.
x-x is not zero if x is an interval.
Just as it is tricky to deal with symbols that can
assume values
of infinity or undefined. I'm thinking about it...
one idea
to prevent inf-inf from simplifiying to 0 is to
generated
indexed values e.g. inf[1]-inf[2] would not
disappear.
Another simplification process would take this and
change
it to (say) undefined[3].
Another issue with infs is 0*inf should be und.
We hope to handle this without making routines
operations
significantly slower.
RJF
----- Original Message -----
From: Raymond Toy <raymond.toy at ericsson.com>
Date: Friday, May 5, 2006 5:52 am
Subject: Re: [Maxima] Re: Interval Arithmetic project
> >>>>> "Richard" == Richard Fateman
<fateman at EECS.Berkeley.EDU> writes:
>
> Richard> This application of interval analysis
for numeric
> Richard> sub-type determination at compile time
seems to me to be
> Richard> rather different from computation with
intervals, as is
> Richard> done by Mathematica ( using
Interval[{a,b }].) There may
> Richard> be more of a relationship than I see
right here, but I
> Richard> think the primary use of this CMU
stuff is to determine
> Richard> when possible that (sqrt x) will
return a [real]
> Richard> double-float and not a complex number.
>
> Yes, CMUCL uses this for type-derivation and is
mostly so the compiler
> knows that sqrt or log will return a real number
instead of real or
> complex.
>
> I'm not familiar with Mathematica's interval
computation, but if
> Interval[{a,b}], where a and b are numbers, then I
would think it's
> similar, except that CMUCL doesn't do directed
rounding.
>
> Ray
>
>