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

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