Re: RE: Re: Workaround for an unexpected behavior of Sum

*To*: mathgroup at smc.vnet.net*Subject*: [mg91139] Re: [mg91105] RE: [mg91067] Re: [mg91036] Workaround for an unexpected behavior of Sum*From*: Andrzej Kozlowski <akoz at mimuw.edu.pl>*Date*: Thu, 7 Aug 2008 04:40:01 -0400 (EDT)*References*: <200808040723.DAA13823@smc.vnet.net> <200808050802.EAA09815@smc.vnet.net> <200808060906.FAA22342@smc.vnet.net> <FABC5C63-A896-4B61-93DD-0FB62737E92A@mimuw.edu.pl>

Sorry, a silly error crept into the code: > Protect[sumFlag]; should have been (of course) Protect[Sum] Andrzej Kozlowski On 6 Aug 2008, at 17:37, Andrzej Kozlowski wrote: > Actually, you can also do that with the Module approach, which I > think is simpler than yours, and the only minor nuisance is having > to set a global flag. Here is the standard way to do this: > > Unprotect[Sum]; > sumFlag = True; > > Sum[sumand_, before___, {dummyindex_, rest___}, after___] := > Block[{sumFlag = False}, > Module[{dummyindex}, Sum[sumand, before, {dummyindex, rest}, > after]]] /; > sumFlag === True > Protect[sumFlag]; > > j = 7; > Sum[j^2, {j, 1, n}] > (1/6)*n*(n + 1)*(2*n + 1) > > Sum[f[j], {j, 1, n}] > Sum[f[j$550], {j$550, 1, n}] > > Note that in the case of Product you get somewhat different behavior > from the case of Sum: > > Product[j^2, {j, 1, n}] > 49^n > > Product[f[j], {j, 1, n}] > During evaluation of In[15]:= General::ivar:7 is not a valid > variable. >> > During evaluation of In[15]:= General::ivar:7 is not a valid > variable. >> > Product[f[7], {j, 1, n}] > > This confirms that the behavior of Sum is a bug. > > Andrzej Kozlowski > > > > > On 6 Aug 2008, at 11:06, Jose Luis Gomez wrote: > >> Dear Andrzej >> >> Thank you for answering my post. First let me answer your comment, >> second I >> will ask if you can do something for me >> >> The "advantage" (not really an advantage, better: the behavior that >> I like) >> is that, after evaluating one time the (yes, very complex) code of my >> approach, after that the behavior of Sum is changed for "ever" (in >> that >> Mathematica session, of course), then you can use Sum (even better, >> you can >> use the palette BasicMathInput) as many times as you want, using the >> standard notation for sums, and not worrying about names of dummy >> indices >> conflicting with names of global variables. >> >> Oversimplifying: if I want to do only few sums, it is better your >> Module >> approach. I want to use many many times the command Sum, and I do >> Not want >> to check for possible conflicts with global variables, neither use >> Module >> every time I use sum, then evaluating one time the complex code I >> posted >> could be a good idea. >> >> Now Andrzej, would you be so kind to use some of your time to >> comment on the >> documentation for my Mathematica package Quantum in the following >> two links? >> Both are related with this issue, and I am very very interested in >> your >> comments and criticisms to the behavior of our package. These are >> the two >> links: >> (please notice that long urls are usually broken in this forum, so >> you might >> have to "glue together" each hyperlink) >> >> http://homepage.cem.itesm.mx/lgomez/quantum/sums/sums.html >> >> http://homepage.cem.itesm.mx/lgomez/quantum/tprodtpow/tprodtpow.html >> >> I really hope you find them interesting enough to comment >> >> Regards! >> >> Jose >> Mexico >> >> >> -----Mensaje original----- >> De: Andrzej Kozlowski [mailto:akoz at mimuw.edu.pl] >> Enviado el: Martes, 05 de Agosto de 2008 03:02 >> Para: mathgroup at smc.vnet.net >> Asunto: [mg91067] Re: [mg91036] Workaround for an unexpected >> behavior of Sum >> >> I don't understand what you consider to be the advantage of your >> approach over the (to my mind) much simpler: >> >> j = 7; >> Module[{j}, Sum[g[j], {j, 1, n}]] >> Sum[g[j$679], {j$679, 1, n}] >> >> Andrzej Kozlowski >> >> On 4 Aug 2008, at 09:23, Jose Luis Gomez wrote: >> >>> Workaround for an unexpected behavior of Sum >>> >>> >>> >>> Let me describe the problem, before describing the solution >>> (workaround) >>> that I found. >>> >>> >>> >>> First: Next calculation works fine for me: >>> >>> >>> >>> j = 7; >>> >>> >>> >>> Sum[j^2, {j, 1, n}] >>> >>> >>> >>> Mathematica gave the answer I was expecting (n*(1 + n)*(1 + 2*n))/6, >>> It >>> means the global j and the dummy index j are actually different That >>> is >>> o.k., that is what I was expecting >>> >>> >>> >>> HOWEVER Next calculation gives an unexpected answer: >>> >>> >>> >>> Clear[f]; >>> >>> >>> >>> j = 7; >>> >>> >>> >>> Sum[f[j], {j, 1, n}] >>> >>> >>> >>> Now Mathematica answers n*f[7]. That is NOT what I was expecting >>> >>> >>> >>> I was expecting that Mathematica will return the Sum unevaluated, >>> Sum[f[j], >>> {j, 1, n}], and also with j unevaluated, so that the global j and >>> the dummy >>> index j remain different. >>> >>> >>> >>> NOW MY WORKAROUND FOR THIS "PROBLEM": AUTOMATICALLY CREATE A NEW >>> DUMMY INDEX >>> IF THERE EXISTS A VARIABLE WITH THE SAME NAME AS THE DUMMY INDEX. >>> Evaluate >>> this in your Mathematica session: >>> >>> >>> >>> Unprotect[Sum]; >>> >>> >>> ReleaseHold[ >>> >>> Hold[Sum[sumando, before, {dummyindex, rest}, after]] /. >>> >>> HoldPattern[dummyindex] :> >>> >>> Evaluate[ >>> >>> Unique[ToString[Unevaluated[dummyindex]]]]] /; >>> >>> (dummyindex =!= Unevaluated[dummyindex]); Protect[Sum]; >>> >>> >>> >>> Now, after the evaluation of the previous code, Mathematica behaves >>> the way >>> I was expecting: >>> >>> >>> >>> Clear[f]; >>> >>> >>> >>> j = 7; >>> >>> >>> >>> Sum[f[j], {j, 1, n}] >>> >>> >>> >>> This time Mathematica answers Sum[f[j1],{j1,1,n}]. >>> >>> The price we have to pay is that the dummy index was renamed. >>> >>> But it is a DUMMY INDEX, it can have any name. >>> >>> And the code makes the new name totally new, thanks to the Unique[] >>> command. >>> >>> AFAIK this code does Not affect the answers of Sum in other cases. >>> >>> >>> >>> I hope this simple solution is somehow useful. >>> >>> Notice that the command Integrate has a similar (in my opinion odd) >>> behavior, mixing dummy integration variables with global variables >>> when the >>> definite integral cannot be immediately performed. >>> >>> >>> >>> Best regards! >>> >>> >>> >>> Jose Luis Gomez-Munoz >>> >>> >>> >>> Mexico >> >> >> >> >> >

**References**:**Workaround for an unexpected behavior of Sum***From:*"Jose Luis Gomez" <jose.luis.gomez@itesm.mx>

**Re: Workaround for an unexpected behavior of Sum***From:*Andrzej Kozlowski <akoz@mimuw.edu.pl>

**RE: Re: Workaround for an unexpected behavior of Sum***From:*"Jose Luis Gomez" <jose.luis.gomez@itesm.mx>

**RE: RE: Re: Workaround for an unexpected behavior of Sum**

**Re: RE: Re: Workaround for an unexpected behavior of Sum**

**RE: RE: Re: Workaround for an unexpected behavior of Sum**

**Re: RE: Re: Workaround for an unexpected behavior of Sum**