       Re: Pattern Matching Mathematica 6 versus 5.2?

```Chris Chiasson wrote:
> I have noticed that the 6.0 pattern matcher is a bit better at
> properly ordering DownValues when a more general (but earlier-defined)
> DownValue would block a less general (later-defined) DownValue. By
> default, DownValues are supposed to be used in decreasing order of
> generality, but if the pattern matcher can't determine which rule to
> apply first, then the order is "first come first serve."
>
> In other words, perhaps you should check to see what order the
> DownValues of Grading and NonCommutativeMultiply have in 6.0 and
> reorder your code so that it defines them in that order.

Hi,

In this case the difference is actually caused by the same bug fix that was
mentioned here:

http://forums.wolfram.com/mathgroup/archive/2007/Jun/msg00104.html

E.g., try

In:= Attributes[f] = {Flat, Orderless, OneIdentity};
f[x_, x_] /; OddQ[Grading[x]] := 0

In:= f[foo, foo]
Out= 0

In:= f[foo, foo, foo]
Out= f[0, foo]

If you try this in 5.2, the last result will be f[foo,foo,foo], because the
condition prevented f's attributes from being taken into account. A simple
workaround in version 5.2 would be use the equivalent form

f[x_, x_] := 0 /; OddQ[Grading[x]]

Now the attributes are indeed used. The key difference is that the Head of
the LHS of the definition is f rather than Condition.

It's true that the automatic DownValues ordering has also been improved in
version 6. It should now never reorder rules that shouldn't be reordered
(although examples of this are usually fairly subtle). The ordering
algorithm used can be controlled by a system option

SetSystemOptions["DefinitionsReordering" -> val]

where val is "Default", "Legacy" (5.2 behavior), or "None". The "None"
option can be useful to set temporarily when reading in a file with
thousands of definitions for which you know you don't need reordering.

Oyvind Tafjord
Wolfram Research

>
> On 6/8/07, Michael Weyrauch <michael.weyrauch at gmx.de> wrote:
>> Hello,
>>
>>   I encounter the following different behaviour of the Mathematica pattern matcher
>> version 6 versus 5.2.
>>
>> I give to both versions the following rules (which should implement a simple
>> Grassmann algebra):
>>
>> Fermion[a_, b___] := ((Grading[a] = 1); Fermion[b]);
>>
>> Unprotect[NonCommutativeMultiply];
>> NonCommutativeMultiply[x_, y_ /; EvenQ[Grading[y]]] := x y;
>> NonCommutativeMultiply[y_ /; EvenQ[Grading[y]], x_] := x y;
>> NonCommutativeMultiply[x_, x1_ y_ /; EvenQ[Grading[y]]] := y (x ** x1);
>> NonCommutativeMultiply[x_ y_ /; EvenQ[Grading[y]], x1_] := y (x ** x1);
>> NonCommutativeMultiply[x_, x_] /; OddQ[Grading[x]] := 0;
>> NonCommutativeMultiply[y_ /; OddQ[Grading[y]], x_ /; OddQ[Grading[x]]] /; (! OrderedQ[{y, x}]) := -x ** y;
>> Protect[NonCommutativeMultiply];
>>
>> Now in version 6 I get e.g.
>>
>> In:= Fermion[f1, f2, f3, f4]
>> Out= Fermion[]
>>
>> In:= f1 ** f2 ** f1 ** f4
>> Out= 0
>>
>> which is as expected, since there a two equal factors.
>>
>> BUT in version 5.2
>>
>> In:=Fermion[f1, f2, f3, f4]
>> Out=Fermion[]
>>
>> In:=f1**f2**f1**f4
>> Out=f1**f2**f1**f4
>>
>> which is NOT as it should be.  Mathematica 5.2 fails to simplify this automatically to zero.
>>
>> I implemented the above rules on the advice of David Bailey, who tried to convince me that the Mathematica pattern matcher makes
>> full use of the attributes Flat and OneIdentity, which are given to NonCommuativeMultiply. This means that it should be only
>> necessary to deal explicitly with the 2-argument case (as I do above).
>>
>> >From the results given above , I am not so sure that this holds in version 5.2? Do I misunderstand something? Or is my code buggy?
>> Can it be changed that in 5.2 it runs as in 6.0?
>>
>> Thanks for hints,   Michael
>>
>>
>>
>
>

```

• Prev by Date: Re: Re: Re: v6: still no multiple undo?
• Next by Date: Re: Re: Re: Re: v6: still no multiple undo?
• Previous by thread: Re: Pattern Matching Mathematica 6 versus 5.2?
• Next by thread: Re: Pattern Matching Mathematica 6 versus 5.2?