Inconsistent behavior when ^ operates on an equation



On 8/10/2013 10:24 AM, Jorge Calvo wrote:
> ...
> but presumably we would eventually want:
>
> (%i2) (a=b) ^ (c=d);
> (%o2) a^c = b^d
>
> This makes sense since raising equal quantities to the equal powers should give equal results.

I think you are relying on semantics for "=" that is not how "=" is used 
in Maxima.

For example, consider
solve (a*x+b=0,x).

The "=" is not asserting that a*x+b=0 always, but is a way of formatting 
a formula in order to
ask a question.  In this case, asking, for what value(s) of x is the lhs 
and rhs equal.
Does it may sense to utter

solve ((a=b)^(c=d), a) ?

would a sensible answer be a=b^(d/c)   ?

If you believe that in fact a=b and c=d, then your expression reduces 
to   true^true.  or if
that goes too far, you might also
say that (a^c=a^d )  and (b^c= b^d)  .

(Maxima does not allow the syntax a=b=c.  It does allow (a=b)=c, and has 
a complicated system
by which   is ((a=b)=c)   evaluates to false...)



>   However, it seems that my suggestion is not the result obtained by mapping over one argument and then another in either order, so perhaps this case would require yet another branch.  Assuming I figure out how to fix the problem with a^(b = c), I can try to fix this one as well.
>
> 2. Or, Try map(exp, a=b) which does what you want.
> more generally  map(f, expression) can apply any function f, e.g. f(r):=sin(r^3)^2.
> It might be nice to show students  map and even lambda.,
> e.g.  map (lambda([r],sin(r^3)^2),   expression)
>
> Using map was an excellent suggestion, and I would be happy to introduce it earlier in the course.  Lambda, however, seems a little too advanced at this stage if the game.  We are exploring computer algebra as a prelude to programming, so the students at this point would not have even learned about user-defined functions.  At any rate, I was excited about the map solution until I realized that:
>
> (a) It requires lambda for operators like + and ^, and
Not really,   map("+",a=b,c=d)  works.  The quotes around the + are 
there because
the syntax for the language would otherwise have to allow for strange 
arrangements
of operators like + and * in places where function names are expected.

>
> (b) it does not work with exp() in bracketed equations (like the result of a failed solve()), as in my original example.  For example:
>
> (%i4) solve(log(x) + log(x+9) = 2*log(6));
> (%o4) [log(x) = 2*log(6)-log(x+9)]
> (%i5) map(exp, %);
> (%o5) [%e^(log(x) = 2*log(6)-log(x+9))]
You may need to distinguish lists from equations in your explanations.  
In general, explanation of
algebraic expression trees with operators and operands would seem to be 
useful.  If any
of your students think that computer algebra is really just hacking away 
at strings of
characters, it might be refreshing to them to explain that it doesn't 
work that way.

>
> I suppose that I could introduce an index and try something like:
>
> (%i7) solve(log(x) + log(x+9) = 2*log(6));
> (%o7) [log(x) = 2*log(6)-log(x+9)]
> (%i8) [map(exp, %[1])];
> (%o8) [x = 36/(x+9)]
There is simply a difference between operating on a list and on 
operating on each element of the list, and
operating on each element of each element of a list.   There is a trick 
operating here in that  a+b+c is
treated implicitly as a list (a,b,c),  but with an operator "+". Another 
reason to talk about algebraic trees:
there is only one "+:" in a+b+c+d ...    because it is sort of like 
"+"(a,b,c,d, ...).

(syntactically,  ?mlist(a,b,c)   comes out as [a,b,c]  )

>
> but again, the inconsistency is a little annoying (for me) and likely confusing (for my students).
Actually, this is not inconsistency you are observing, but consistency.

>
> 3. I will have to investigate simp.lisp further to see how the issue is handled for + (which I gather is simplus) and try to imitate it for simpexpt.  Of course, I will need to understand both these function a little more than I now do?
Have fun learning about the simplifier. The basic outline of the program 
is due to Knut Korsvold who wrote it
in 1963.  Note that lisp was invented only a few years earlier.

RJF


>