It is too big a change to make solve() return a Boolean expression, which
is totally general and includes the degenerate cases 'true' and 'false'.
There could, however, be a new function or an option parameter that does
this.
However, another possibility is to return [true].
Dsadvantages of 'all' are:
1. It is yet another identifier (not indexed in the online documentation)
that must be dealt with in functions that invoke solve().
2. 'all' is type inconsistent with the other alternatives, which are
either a list of equations or a list of lists of equations.
Two disadvantages of returning a result containing %r_n are:
1. It introduces another indeterminate, which increases complexity and
visual clutter.
2. The n can vary among sessions depending on the history, so the result
isn't unique and it complicates writing functions that process a solve
result -- including recognizing when two solutions are essentially
duplicates.
-- david stoutemyer
On Wed, Mar 20, 2013 at 12:09 PM, Stavros Macrakis <macrakis at alum.mit.edu>wrote:
> solve has three ways of representing "all values of *var* satisfy the
> equation":
>
> solve(x=x,x) => all
> solve(1+1/x-(x+1)/x,x) => [x=x] ... this seems like a bug
> solve([x=x,x=x],x) => [[x=%r1]] ... returned by algsys
>
> Wouldn't it be better if we standardized on one of these? I would propose
> the %r1 solution.
>
> I imagine there are a few scripts that special-case the 'all' solution --
> I wonder what happens to them if %r1 is returned? Some might even work
> correctly without modification.
>
> I suspect that most scripts that get the x=x solution incorrectly treat
> that as a non-solution because the RHS includes *var* (like solve(f(x)=x)
> => [x=f(x)]).
>
> Thoughts?
>
> -s
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>
>