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

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
>
>
>
>
  • Prev by Date: Re: Possible bug in Fits.exe on Mac OSX Mathematica 6.0.3
  • Next by Date: Re: RE: Re: Workaround for an unexpected behavior of Sum
  • Previous by thread: RE: Re: Workaround for an unexpected behavior of Sum
  • Next by thread: Re: RE: Re: Workaround for an unexpected behavior of Sum