[Date Index]
[Thread Index]
[Author Index]
Re: RE: Re: Workaround for an unexpected behavior of Sum
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: Use of RuleDelayed in PaneSelector**
Previous by thread:
**Re: RE: Re: Workaround for an unexpected behavior of Sum**
Next by thread:
**Re: Workaround for an unexpected behavior of Sum**
| |