On 4/2/07, Robert Dodier <robert.dodier at gmail.com> wrote:
> On 4/2/07, Stavros Macrakis <macrakis at alum.mit.edu> wrote:
> > ...it *is* actually consistent with the basic meaning of "solve"
> I'm sorry, I don't agree with this at all.
>
> "Return the values of vars which make eqs true" is one interpretation of
> solving eqs for var,
Perhaps I wasn't clear. I was talking about the "basic meaning" of
Maxima's current solve command, not about some abstact notion of
solving in general. Then I gave some examples to motivate why the
current behavior might be sensible.
> but another, which seems no less natural,
> is "conclude what you can about vars given eqs". If eqs includes
> enough to draw conclusions about vars plus some irrelevant stuff,
> the presence of the irrelevant stuff is no need for us to fail.
It may be possible to make this work. But what do you do about
solve(x*p=x,x)
Currently, Maxima returns x=0, the only solution true for all p. But
if you interpret parameters so that there only have to be solutions
for *some* values, then the correct answer is ALL, because for p=1, it
is true for all x. If you want to see if it is true for some values
of x and p, you use
solve(x*p=x,[x,p])
which gives
[[x=0,p=%r1], [x=%r2,p=1])
Maxima has chosen to have solve/linsolve/algsys use the for-all
interpretation, which has certain nice properties. Maybe there should
also be a for-some function, which has different nice properties. At
that point we can discuss which one should be the *basic* meaning of
solve. And let's keep in mind not just the interactive use of solve,
but also the programmatic, where clear-cut semantics are even more
important.
-s