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

*To*: mathgroup at smc.vnet.net*Subject*: [mg91138] 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:39:50 -0400 (EDT)*References*: <200808040723.DAA13823@smc.vnet.net> <200808050802.EAA09815@smc.vnet.net> <200808060906.FAA22342@smc.vnet.net>

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>