Re: AW: Problem with Mathematica 6
- To: mathgroup at smc.vnet.net
- Subject: [mg77134] Re: AW: [mg77065] Problem with Mathematica 6
- From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
- Date: Mon, 4 Jun 2007 03:57:28 -0400 (EDT)
- References: <JNEIICAJLELPIHHIMDJDAEOMCDAA.michael.weyrauch@gmx.de>
I don't disagree with you but my point was somewhat different. I seems to me that just as WRI does not "take responsibility" for changes in functions in contexts like Internal` (one of my favorite functions has from that context, Internal`DistributedTermsList has disappeared and got replaced by CoefficientArrays, naturally without any documentation about this change) so it does not take responsibility for any incompatibility resulting from modifying built- in functions by users. I think that is a reasonable policy. However in this case I admit that my first reaction was based on a mistaken belief that the change that took place was "invisible" to the user unless a function was modified. In fact, there seem to have been significant changes to the pattern matcher which affect even user defined functions. From what I have been able to discover by experimenting with pattern matching, they appear to be more consistent with what one intuitively expects of patterns involving attributes such as Flat etc. As for your problem: Carl Woll's solution (using HoldPattern) seems quite satisfactory to me - is there anything wrong with it? The only unsatisfactory thing, as far as I am concerned, is that the changes to the pattern matcher appear to be completely undocumented. Andrzej Kozlowski On 3 Jun 2007, at 19:04, Michael Weyrauch wrote: > Dear Andrzej, > > thanks very much for your answers. > > In this particular case, I dare to disagree with you and David > Withoff. > > The reason is twofold: > > 1) NonCommutativeMultiply is a completely featureless function, just > implemented with the Attributes Flat and OneIdentity. So by > changing > it, you cannot really interfere with anything. (At least this is my > opinion and > experience. Of course, I do not really know the actual > implementation.) > > 2) If you give a self-implemented function the attributes Flat and > OneIdentity > you run into the same issues I described in my post. > > So the issue really is connected with the handling of the > Attributes Flat > and OneIdentity, which obviously changed from Mathematica 5.2 to 6.0 as the > post > by Carl Woll and your own investigations suggest. > > At this moment, it is hard for me to judge, if the new behaviour is > "better" > or not. > I just have little criteria how it should work. > I just realize that the code for Grassmann variables I use does not > work > in Mathematica 6.0. > > I need to investigate this further. > > Michael > > > -----Ursprungliche Nachricht----- > Von: Andrzej Kozlowski [mailto:akoz at mimuw.edu.pl] > Gesendet: Sonntag, 3. Juni 2007 08:58 > An: Michael Weyrauch; mathgroup > Cc: Andrzej Kozlowski > Betreff: Re: [mg77065] Problem with Mathematica 6 > > > In my reply I omitted the question of possible reason for the new > behaviour. I did that because when I was replying I had not yet > investigated this problem and, given that this phenomenon involves > unprotecting a built-in function, I did not think the precise reason > was relevant. I have not changed my mind about that, but now I think > that what you have observed is a consequence of changes that have > been made in the pattern matcher, which do not seem to me to involve > any obvious bug and perhaps represent an improvement. To see what I > mean compare these two outputs: > > First Mathematica 5.2: > > > a**b /. (NonCommutativeMultiply[x___] /; (Print[{x}]; > Length[{x}] <= 1)) :> f[x] > > > {a,b} > > a**b > > > Now Mathematica 6: > > In[7]:= a ** b /. NonCommutativeMultiply[x___] /; (Print[{x}]; > Length[{x}] <= 1) :> f[x] > > {a, b} > {a} > > Out[7]= f[a] ** b > > Note that Mathematica 6.0 actually went inside the expression a**b > and used the attribute Flat to find a match for > NonCommutativeMultiply[x___]/Length[{x}] <= 1), while Mathematica 5.2 > looked only at the top level and did not find any match. This > suggests to me that the new behaviour is more likely an improvement > over the old rather than a bug. Anyway, whatever the reason, the > advice not to unprotect built-in functions still stands. > > Andrzej Kozlowski > > > > On 2 Jun 2007, at 21:49, Andrzej Kozlowski wrote: > >> *This message was transferred with a trial version of CommuniGate >> (tm) Pro* >> >> On 2 Jun 2007, at 17:19, Michael Weyrauch wrote: >> >>> Hello, >>> >>> the following code fragment runs under Mathematica 5.2 but >>> produces an infinite recursion error in Mathematica 6.0 in certain >>> cases: >>> >>> First I define a number of commands and slightly change the >>> built-in command "NonCommutativeMultiply": >>> Grading[_] = 0; >>> Fermion[a__] := ((Grading[#1] = 1) & ) /@ {a}; >>> Fermion[a, b]; >>> GetGradeds[a___] := GetGradeds[a] = Select[{a}, Grading[#1] != 0 >>> & ]; >>> >>> Unprotect[NonCommutativeMultiply]; >>> NonCommutativeMultiply[a___] /; (Length[GetGradeds[a]] <= 1) := >>> Times[a]; >>> Protect[NonCommutativeMultiply]; >>> >>> If you now e.g. evaluate >>> >>> In[22]:= k ** l >>> Out[22]= k*l >>> >>> or >>> >>> In[23]:= a ** l >>> Out[23]= a*l >>> >>> BUT in Mathematica 6.0: >>> >>> In[24]:= a ** b >>> >>> $IterationLimit::"itlim" : "Iteration limit of 4096 exceeded. \ >>> \!\(\*ButtonBox["\[RightSkeleton]", >>> BaseStyle->"Link", >>> ButtonData:>"paclet:ref/message/$IterationLimit/itlim", >>> ButtonFrame->None, >>> ButtonNote->"$IterationLimit::itlim"]\)" >>> Out[24]= Hold[(Times[a]) ** b] >>> >>> However in Mathematica 5.2 one gets >>> >>> In[10]:= a ** b >>> Out[10]=a**b >>> >>> which is what I expect and I want to have. >>> >>> I.e., whenever I NonCommutativeMultiply two variables which are >>> explicitly declared as fermions by the command Fermion[], I get an >>> infinite recursion error in Mathematica 6. >>> >>> This behaviour of Mathematica 6.0 is rather confusing to me, since >>> I believe that I just use very basic and elementary assignments >>> in my code. Why shouldn't it work under Mathematica 6.0 if it >>> works under 5.2? It appears that the 6.0 kernel behaves >>> differently than the >>> 5.2 kernel in such basic situations. Very unpleasant! >>> >>> (For anyone who wonders about the purpose of this (strange) code: >>> It is a small fragment of a package that implements the handling >>> of Grassmann variables. I just extracted that bit in order to show >>> the Mathematica 6.0 problem.) >>> >>> Furthermore, beyond an explanation of this unexpected behaviour of >>> Mathematica 6, I would like to find a workaround in Mathematica 6 >>> such that I get >>> the same result as in Mathematica 5.2. >>> >>> Thanks for any suggestions. >>> >>> Michael Weyrauch >>> >> >> On of the most basic principles in Mathematica programming, stated, >> over the years, a number of times on this list by WRI employees, >> (particularly by David Withoff) is if you choose to Unprotect and >> modify any built-in functions you can only blame yourself for any >> unpleasantness that might occur. The workaround is: don't do it. >> >> One think you can do instead is to do essentially the same thing >> without modifying NonCompputativeMultiply. If you want to use a >> symbol that looks like multiplication you could choose SmallCircle. >> You could then do something like this: >> >> In[1]:= Grading[_] = 0; >> In[2]:= Fermion[a__] := ((Grading[#1] = 1) &) /@ {a}; >> In[3]:= Fermion[a, b] >> Out[3]= {1, 1} >> In[4]:= GetGradeds[a___] := GetGradeds[a] = Select[{a}, Grading >> [#1] != 0 &]; >> In[9]:= SmallCircle[z___] /; (Length[GetGradeds[z]] <= 1) := Times >> [z]; >> In[10]:= SmallCircle[z___] := NonCommutativeMultiply[z] >> >> In[13]:= SmallCircle[a, l] >> Out[13]= a l >> >> SmallCircle[a,b] >> >> In[14]:= SmallCircle[a, b] >> Out[14]= a ** b >> >> In[17]:= SmallCircle[a, l, m] >> Out[17]= a l m >> >> Of course instead of writing SmallCircle[a,l,m] you can use as >> input a escape sc escape l escape sc escape m . >> >> Andrzej Kozlowski >