RE: Re: Workaround for an unexpected behavior of Sum

*To*: mathgroup at smc.vnet.net*Subject*: [mg91197] RE: [mg91172] Re: Workaround for an unexpected behavior of Sum*From*: "Jose Luis Gomez" <jose.luis.gomez at itesm.mx>*Date*: Sat, 9 Aug 2008 07:45:11 -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> <g7ed4j$2o3$1@smc.vnet.net> <200808081115.HAA11668@smc.vnet.net>

Well, it is so great to have these responses to my post. Thank you too, Albert Another issue, somehow related with your answer, Albert, is that Mathematica has two different ways to specify double sums, the two of them format the same in standard form (with the sigma notation), but they are not consider to be equal by Mathematica (I already posted this in another thread of this forum, however I considered relevant to mention it again): Evaluate in a Mathematica notebook this code: Sum[Sum[f[j], {j, 1, k}], {k, 1, n}]==Sum[f[j], {k, 1, n}, {j, 1, k}] As you can see, both sides of the equation display exactly equal in a notebook, using two sigmas, etc. However Mathematica does not simplify this to True, not even using Simplify or Reduce: Simplify[ Sum[Sum[f[j], {j, 1, k}], {k, 1, n}]==Sum[f[j], {k, 1, n}, {j, 1, k}] ] Mathematica is a great software, I feel happy of making a small contribution to possible improvements/fixes. I already reported these two issues (dummy index versus global variables, and nested sums not equal to two-indices form) to the support team of Wolfram Research. Please if anyone has further ideas besides those of Andrzej and Albert, I will certainly be happy to read about them Best regards Jose Mexico -----Mensaje original----- De: Albert Retey [mailto:awnl at gmx-topmail.de] Enviado el: Viernes, 08 de Agosto de 2008 06:15 Para: mathgroup at smc.vnet.net Asunto: [mg91172] Re: Workaround for an unexpected behavior of Sum Hi, > 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! I'm not in a position to criticize Adrzejs approach, but the following solution seems to achieve the same in a different way and has some advantages in my opinion, so it might also be of interest. By using ValueQ (or accessing OwnValues directly) you can easily decide whether or not a Symbol has a value without evaluating. So something like this would also do the job: Unprotect[Sum]; Sum[ sumand_, before___, {dummyindex_Symbol /; ValueQ[dummyindex], rest___}, after___ ] := Module[{dummyindex}, Sum[sumand, before, {dummyindex, rest}, after] ]; Protect[Sum]; I'm sure this approach has it's limits too (there could be additional trouble with UpValues or DownValues of the index), but I like it for the following reasons: 1) no dependence on the state of a global variable, which for whatever reason could be left in an inappropriate state (see e.g. nested sums below). 2) it is minimal invasive: it only intervenes when obviously necessary 3) it works also with nested sums: j=1;k=2; Sum[Sum[f[j], {j, 1, k}], {k, 1, n}] j = 1; k = 2; Sum[f[j, k], {k, 1, n}, {j, 1, k}] >> This confirms that the behavior of Sum is a bug. >> >> Andrzej Kozlowski After all a reliable solution can only be achieved by Wolfram in this case, everything else is just a workaround... hth, albert

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

**Re: Workaround for an unexpected behavior of Sum***From:*Albert Retey <awnl@gmx-topmail.de>