RE: Re: Workaround for an unexpected behavior of Sum

*To*: mathgroup at smc.vnet.net*Subject*: [mg91105] RE: [mg91067] Re: [mg91036] Workaround for an unexpected behavior of Sum*From*: "Jose Luis Gomez" <jose.luis.gomez at itesm.mx>*Date*: Wed, 6 Aug 2008 05:06:07 -0400 (EDT)*References*: <200808040723.DAA13823@smc.vnet.net> <200808050802.EAA09815@smc.vnet.net>

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

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

**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: Please help me.....**

**Re: Find count of binary number pattern within concatenated number**

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

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