Robert Dodier wrote:
> On 3/1/09, Richard Fateman <fateman at cs.berkeley.edu> wrote:
>
>> let s(c):= (x^2+x+2)/(x^2+x+c);
>>
>> Now consider integrate(s(c),x);
>>
>> Maxima gives two possible answers depending on the sign of 4*c-1. call
>> them A(x,c) and B(x,c).
>
>> In fact this is a bug in Maxima because it should provide yet a third
>> form of the answer for 4*c-1=0.
>
> Agreed, that's a bug. I'll make a bug report about it if there isn't
> one already.
>
>> bfloat(rectform(subst(x=1.0, subst(c=1/8, integrate(s(c),x)) =
>> integrate(s(1/8),x))));
>> bfloat(rectform(subst(x=1.0, subst(c=4, integrate(s(c),x)) =
>> integrate(s(4),x))));
>
>> These two examples in Maxima require that you answer a question, and the
>> alleged equation is true only if you answer the question correctly.
>
> Well, that's exposes a failure in asksign, right? Because the context
> in which a result was generated is not carried along. That's the point
> of constructing conditional expressions instead of calling asksign.
If you want the result of integrate(s(c),x) to look like
if 4*c>1 then (...) else (....), the consequences are uncomfortable.
>
>> Then a challenge for Maxima is to notice that computing diff(F,x)
>> eliminates all the 'if's and is simply s(c).
>
> Well, if Maxima produces a correct but overly complicated result,
> I'm not too worried, that's certainly much better than throwing the
> conditions by the wayside.
The "overly complicated" can be exponentially larger than the
uncomplicated, and that may make
it impossible to continue to compute at all. For example, consider
if (x>0) then x else if(x<0) then -x else 0
Such expressions can be simplified, e.g. in this case to
abs(x).
or maybe
if realp(x) then abs(x) else error("complex numbers are not ordered")
But the simplification is hard to figure out, if it can indeed be done
at all. And lacking the
simplification, continuing to compute with these expressions piles them
one on top of another.
>
>> Now consider if s(c) involved more parameters. And perhaps iterated
>> integrals.
>
> Well, it will make a mess, but so what? Humans employ computers
> in no small part to grind through simple, tedious computations.
I think it is worth another experiment to implement, since the last time
I was involved in
doing it (with Sam Dooley's MS project), computers were smaller and
slower. Maybe
there could be a branch of Maxima that would try it. I think you
underestimate
the difficulty of carrying it out on non-trivial computations. See the
difficulty
of quantifier elimination, geometric reasoning, and then extend it from
polynomials
in one or two variables to exponential/log/ etc of arbitrary numbers of
variables.
I also suspect that you are overestimating the usefulness of carrying
the geometry
through, step by step.
Consider the use of interval arithmetic for error analysis: generally
the results
are crude. Much more sophisticated error analysis is possible and is
done for
important computations, e.g. forward or backward error analysis of
algorithms.
Perhaps the same kind of analysis can be done for important symbolic
algorithms
"after the fact". For example, let "solve" do all kinds of possibly
incorrect
transformations and check the answers at the very end. (This is not so
easy to
do, but it is an illustration of the idea.)
Contrasting to interval arithmetic, whose cost is a small linear
multiple of the original
computation, tracking all the branches is likely to be costly in space
and time.
> This business about tracking conditions isn't so different,
> conceptually, from adding up a long column of big numbers.
I don't see the analogy. Building trees/ traversing them/ is not linear
in growth.
Or do you mean that anything a computer does is just adding numbers :)
Anyway, anyone who wants to try tracking validity doesn't need a go-ahead
signal from me. But I suggest setting up a branch of Maxima.
RJF