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

*To*: mathgroup at smc.vnet.net*Subject*: [mg91143] RE: [mg91105] RE: [mg91067] Re: [mg91036] Workaround for an unexpected behavior of Sum*From*: "Jose Luis Gomez" <jose.luis.gomez at itesm.mx>*Date*: Thu, 7 Aug 2008 04:40:47 -0400 (EDT)*References*: <200808040723.DAA13823@smc.vnet.net> <200808050802.EAA09815@smc.vnet.net> <200808060906.FAA22342@smc.vnet.net> <FABC5C63-A896-4B61-93DD-0FB62737E92A@mimuw.edu.pl> <56CE1299-6088-4EE5-A34B-55DF275308B9@mimuw.edu.pl>

Yes Andrzej, I agree, you are right, I can see know very important advantages of your approach over mine: ONE: Using the flag, you avoid an infinite loop (actually, infinite recursion). The equivalent action in my approach was to verify if Unevaluated[dummyindex] is the same as the evaluated dummyindex. In my case, the evaluation of dummyindex could take a long time. We actually cannot know in advance how much time would that evaluation take, it depends whatever the end user has stored in dummyindex, which could be a long program that takes a lot of time to evaluate. Even worst, the evaluation of dummyindex could have unwanted results or side effects, again it depends on the content of dummyindex. Therefore my approach is potentially inefficient and potentially dangerous. On the other hand, in your approach you only verify if the flag is True or False: always fast, always safe, always reliable, great! TWO: It is easier also for a human being to understand your code. Mine is so full Hold, ReleaseHold, HoldPattern, it is just ugly. THREE: Your are using standard Mathematica scoping, while I was creating my own version of scoping. Although the dollar sign is (I think) kind of ugly, it is actually a good idea that appears as it does in your approach, because anyone with a minimum knowledge of scoping in Mathematica will recognize what is going on thanks to that dollar sign. So, I totally surrender, your approach is better (though I would change the name of sumFlag to something like sumEnterOneTimeFlag, or something like that). Jose Mexico -----Mensaje original----- De: Andrzej Kozlowski [mailto:akoz at mimuw.edu.pl] Enviado el: Mi=E9rcoles, 06 de Agosto de 2008 10:40 Para: Mathematica news group mailing list CC: Jose Luis Gomez Asunto: Re: [mg91105] RE: [mg91067] Re: [mg91036] 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 > > > >

**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>