Well, I'm glad we have the ball rolling, but ...
On 12/13/07, Richard Fateman <fateman at cs.berkeley.edu> wrote:
> 1. It doesn't make much sense to talk about intervals with symbolic
> endpoints because it almost immediately descends to uselessness. e.g. [a,b]
> op [c,d] = [ min(a op c, a op d, b op c, b op d), max(...)] if op is
> monotonic, and worse if it is not.
I really don't see a problem with symbolic endpoints.
It makes a mess -- so what? That's why people build computers,
right? -- to handle the tedious stuff that people can't or won't.
If it's not useful to you, you don't have to use it.
If some operation doesn't have a well-defined result when it operates
on an interval (e.g. maybe division when the denominator interval
includes zero) then Maxima should just refuse to carry out the
operation; Maxima isn;'t obliged to generate a bogus result.
> 2. It also does not make much sense to take intervals as a full participant
> in simplification with symbols, e.g. x+[-1,1], although this is not subject
> to the combinatorial explosion of paragraph 1.
I don't see a problem with this either.
> There are several rather fully-formed interval arithmetic packages, using
> standard hardware IEEE arithmetic, and even for arbitrary precision e.g. mpfi
Yes, if there is a suitable package for handling intervals which
we could merge in, Maxima could benefit from that.
> For Maxima, consider a new evaluator that has the following features.
>
> a. It has essentially the same arithmetic and control structures as "meval"
> syntactically. In fact, the same parser is used.
> b. It works only on interval or numeric constant objects. (a numeric
> constant 1.234 is equivalent to the interval [1.234,1.234].
> c. It has a few additional operations like subset, overlap,
> absolutely-lessthan, maybe-lessthan ... that make sense for intervals. And
> a few "advanced" operations like "evaluate a polynomial at an interval
> point".
>
> Then to do interval arithmetic, we do something like
> f(x,y,z):=IEVAL(x^2+y-3+....).
Why is there a new evaluator? That sets a bad precedent:
every time we invent a new object, we make a special evaluator for it?
I hope not.
It is much more consonant with the existing system to implement
arithmetic on intervals the same as arithmetic on other objects,
namely, via the simplification system. Whether that means rules
defined via tellsimp/tellsimpafter, or hard-coded Lisp routines,
doesn't matter too much, from the user's point of view.
> (Oh, it also turns out that respect for IEEE rounding may matter,
> and some lisp systems pretty much disrespect this..)
We should probably try to be careful about floating point rounding.
I don't know offhand which Lisps are careful enough about that.
FWIW
Robert