WOLFRAM

Services & Resources / Wolfram Forums / MathGroup Archive

MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

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

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
>>
>>
>>
>>
>>
>
  • Prev by Date: RE: RE: Re: Workaround for an unexpected behavior of Sum
  • Next by Date: Re: RE: Re: Workaround for an unexpected behavior of Sum
  • Previous by thread: RE: RE: Re: Workaround for an unexpected behavior of Sum
  • Next by thread: Re: RE: Re: Workaround for an unexpected behavior of Sum