I don't see what the problem is here.
Matching is not so unusual with respect to potential
ambiguity: You can often use the same name for
conflicting meanings at different times in Maxima. e.g.
assume(x>0)
forget(x>0)
assume(x<0)
It is usually considered bad practice to re-use names, and
so maybe the solution is to provide some kind of convention:
If you use matchdeclare
as in
matchdeclare(x_atom, mapatom);
matchdeclare(x_true, true);
then there should be less opportunity for confusion. Just use
names that make sense, and don't re-define them!
In Mathematica you can define pattern variables in-line, as in
f[x_Integer]:= ....
or
f[x_?pred]:= ...
but you can, I think, redefine pred[] at different times, so it
too has the same potential for ambiguity.
I think that there are definite advantages to Mathematica's overall
approach to pattern matching, since it can incorporate a much more
elaborate combinatorial search/ backtracking. Sometimes that is what you
need for commutative operators. The Macsyma pattern matcher
in some sense "tries harder" to make a match the first time, but
never backs up and tries again. They both can demand subtle
thinking in defining patterns.
Perhaps if you stated, (in natural language?), the kinds of things you
want to do that are function-identity applications, we can figure out
how to do it with rules.
Maybe what you want is to point to certain
subexpressions and apply particular identities only where you point, and
not other places. What is required then is a command like "Do this <here>"
where <here> is a location identified by feedback from a mouse or other
device.
This could be done relatively nicely if the pointing could be translated
into
part(%o45,3,2,2) etc. and the "Do F here" could be translated into
something like
%o45:substpart(F(%o45,3,2,2), 3,2,2)
.
This sounds like a project worth doing, but you need to be able to grab a
specific
component of an expression. A mouse or a stylus can help, if you have the
right software. Or it is possible to use dpart(%o45,3,2,2) to see what
you
are talking about, and maybe after poking around that way, applying an
identity at a point. (A cute hack might be to redisplay -- in the same
place --
as you write down the sequence to navigate to a subexpression, perhaps
changing
the color of the selection. so you could type 3 2 2 oops, no, backspace, 3
...
and this would not require mouse input to be read by maxima.
You might also want to look at ways of displaying identities, which can
often
run --> or <--- . e.g. n*log(x) <--> log(x^n), and choose which
way to
apply.
Anyway, I hope this provides some food for thought. (especially since I
don't understand what you really want for function identity rules!)
RJF
----- Original Message -----
From: "Barton Willis" <willisb at unk.edu>
To: "Robert Dodier" <robert.dodier at gmail.com>
Cc: <maxima at math.utexas.edu>
Sent: Tuesday, May 02, 2006 6:20 AM
Subject: Re: [Maxima] applying function identities (proposal)
> Two defrules can display the same, yet be different:
>
> (%i1) matchdeclare(x,mapatom)$
> (%i2) defrule(r1, f(x),x * f(x-1))$
> (%i3) matchdeclare(x,true)$
> (%i4) defrule(r2, f(x),x * f(x-1))$
>
> Rules r1 and r2 display the same:
>
> (%i5) disprule(r1);
> (%t5) r1:f(x)->x*f(x-1)
> (%o5) [%t5]
> (%i6) disprule(r2);
> (%t6) r2:f(x)->x*f(x-1)
> (%o6) [%t6]
>
> But the rules are different:
>
> (%i7) apply1(f(x),r1);
> (%o7) x*f(x-1)
>
> (%i8) apply1(f(x),r2);
> Maxima encountered a Lisp error:
>
> Maybe somebody would like to take this on as a project---the
> defrule code is too recondite for me to hack. As it is, defrule
> isn't geared toward applying function identities that have
> dummy variables --- defrule is more suited for applying
> substitutions to expressions.
>
>
> Barton
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>