       Re: Pattern Matching Mathematica 6 versus 5.2?

• To: mathgroup at smc.vnet.net
• Subject: [mg77483] Re: [mg77424] Pattern Matching Mathematica 6 versus 5.2?
• From: "Chris Chiasson" <chris at chiasson.name>
• Date: Sun, 10 Jun 2007 07:17:59 -0400 (EDT)
• References: <200706080934.FAA03584@smc.vnet.net>

```That was highly informative. Thank you.

On 6/9/07, Oyvind Tafjord <tafjord at wolfram.com> wrote:
> 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};
> Grading[foo] = 1;
> 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):
> >>
> >> Grading[_Symbol] = 0;
> >> Grading[_Integer] = 0;
> >> Grading[_Rational] = 0;
> >> Grading[_Complex] = 0;
> >> Grading[_Real] = 0;
> >> 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
> >>
> >>
> >>
> >
> >
>
>

--
http://chris.chiasson.name/

```

• Prev by Date: Re: 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: Graphics3D exported to pdf