PART+, was: Re: [Maxima] Yet another units package

I wrote matrun etc about 35 years ago. I don't know it
has been rewritten  (I heard claims that Macsyma Inc rewrote
pieces), but I think the Maxima code is pretty much what I
wrote.  Note that Lisp in the 1960's was less sophisticated
than now.  But I think I can express the intention.
That is,
a pattern that looks like a sum, without any further qualifications,
is a bad idea.
A pattern like a*x^2+b   is OK, if x is not a pattern variable, because
it is qualified.
The generated program looks for the coefficient of x^2 and names it  a.
The sum of everything else is named b.  {subject to predicates..}

A pattern like a+b does NOT try all possible partitions.
I believe that it picks one item for a. Everything else is grouped as b.
This is not because the author was ignorant of re-partitioning possibilities,
but because the author knew that such searches could be expensive.
E.g. the matcher in Mathematica can be given tasks that take exponential
time in the length of the input. The hope was to keep the matcher fast enough
so that it would be useful for simplifier hacking.

Why was this choice made for the macsyma matcher?  Because the other
kind of match was already programmed in macsyma, in the program
"schatchen" written by Joel Moses.  (Schatchen is Yiddish for "matchmaker").
The program is in the SIN or SININT file, and is, I think, called M1.

If you want a top-level matcher that looks more like Mathematica's I suppose
this could be put together by putting together calls to M1, suitably
clothed in various ways.  Or the MockMMA matcher could be moved to
Maxima.
Or for the specific case you could write a program that looks for a
sum  (i.e. inpart(E,0)="+") and then picks out the terms and disposes of
them in whatever way you had in mind.

RJF


Wolfgang Jenkner wrote:

> Robert Dodier  writes:
> 
> 
>>As for the specific example you cited,
>>
>>
>>>You also completely changed some behaviour which I wouldn't
>>>consider as broken.
>>
>>This statement needs qualification.
> 
> 
> This is why I gave the example.
> 
> 
>>>For example, in a fresh session,
>>>
>>>matchdeclare(%b%,atom);
>>>const_true(x):=true;
>>>/* Btw, simply `true' ought to work, too */ 
>>>matchdeclare(%a%,const_true);
>>>defmatch(foo,%b%+%a%);
>>>foo(x+y+y^2+z+cos(x));
>>>
>>>used to give
>>>                         2
>>>[%b% = z + y + x, %a% = y  + cos(x)]
>>>
>>>but with your changes in PART+ (src/matrun.lisp) it now gives
>>>`false'.
>>
>>I don't think we want to reproduce this, since it
>>is incorrect:  atom(z + y + x) => false.
> 
> 
> Maxima tells you what is going on:
> 
> (c4) defmatch(foo,%b%+%a%);
> %b% + %a% partitions `sum'
> 
> So the sum is partitioned in a sum of atoms and a sum of whatever is
> matched by the next predicate, which happens to match anything.  No
> bug here.
> 
> 
>>I want PART+ and PART* to act correctly, but the behavior
>>of the previous version gives rather weak guidance; it is
>>easy to find examples in which it is strange, or flatly wrong. 
>>E.g., in the example above, if the roles of %a% and %b% are
>>exchanged (i.e., %a% is the atom and %b% is anything)
>>the result of foo is different. It is easy to find other
>>examples in which the results depend on the ordering of
>>the formal or actual variables (the existing PART+
>>has inherited this bug).
> 
> 
> %b% comes before %a% in the usual ordering (see Maxima's message
> above).  No bug here.
> 
> 
>>In a new session,
>>
>>  matchdeclare (%a%, atom, %b%, true)$ defmatch (foo ,%b% + %a%)$
>>  foo (x+y+y^2+z+cos(x)); => [%b% = z + y  + y + COS(x) + x, %a% = 0]
>>
>>Hmm, I guess that's not incorrect, but it's still odd -- 
>>why didn't foo try to find a nontrival atom? I guess I'll 
>>give it some encouragement:
>>
>>  nza(e) := atom(e) and e # 0$ matchdeclare (%a2%, nza)$
>>  defmatch (foo2, %b% + %a2%)$ foo2 (x+y+y^2+z+cos(x)); => false
>>
>>Oops.
> 
> 
> Greedy matching.  No bug here.
> 
> 
>>At this point I have two suggestions. (1) Why don't we steer 
>>the discussion towards how we want matching of + and * to work.
> 
> 
> That's an easy one for me.
> 
> Wolfgang
> 
> _______________________________________________
> Maxima mailing list
> Maxima@www.math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima