[Date Index]
[Thread Index]
[Author Index]
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**
| |