Re: Uniform design

*To*: mathgroup at smc.vnet.net*Subject*: [mg48312] Re: Uniform design*From*: Bill Rowe <readnewsciv at earthlink.net>*Date*: Sun, 23 May 2004 06:15:38 -0400 (EDT)*Sender*: owner-wri-mathgroup at wolfram.com

On 5/22/04 at 3:04 AM, ab_def at prontomail.com (Maxim) wrote: >Bill Rowe <readnewsciv at earthlink.net> wrote in message >news:<c8kd99$msp$1 at smc.vnet.net>... >>It seems to me far more natural to due either Sum[n, {n, 10^6}] or >>Sum[n, {n,k}]/.k->10^6 then what you've shown. Not only are these >>more natural, they are faster and avoid the bug. >I'm not so sure about it being a bug; what is happening here is >that for values not greater than 10^6 Sum works as an iterator >should (chapter A.4.2 of the Book), but for larger values Sum calls >SymbolicSum`SymbolicSum, which pre-evaluates the first argument; so >cnt+=1 evaluates to 1 and we're summing 10^6+1 ones. The >documentation says that it is done only for symbolic sums (that is, >when there are non-numerical quantities in the iterator), I didn't look at the documentation before posting. So, perhaps I should not have called this behaviour a bug. But the point remains, It seems far more natural to use either Sum[n, {n,10^6}] or Sum[n, {n, k}]/.k->10^6 than Module[{cnt =0}, Sum[cnt += 1, {i, 10^6 + 1}] ]. That is you seem to be going out of your way to create problems. >SymbolicSum`SymbolicSum adds its share of confusion too, because it >is also HoldAll and performs some preliminary operations on the >arguments before evaluating them; in particular, it looks for Out >in the first argument. As a result, we get the following: >In[1]:= a=k; Sum[a,{k,n}] >Out[2]= k*n >In[3]:= a=k; Sum[%,{k,n}] >Out[4]= n*(n+1)/2 This too, seems like an example where you are going out of your way to make things difficult. For a simple case such as this, why would anyone want to create a second variable to be evaluated rather than simply writing Sum[k, {k,n}]? And for those cases where a is a more complicated expression of k, i.e., not easily typed, simply doing Sum[Evaluate@a, {k,n}] solves the problem. The point is it seems far more natural to make dependencies explicit. Not only does this remove the issue, it makes it easier to understand the code later. -- To reply via email subtract one hundred and four

**Re: Eigensystem: different solution in V5.0 and V4.1 ??**

**Re: optimally picking one element from each list**

**Re: Uniform design**

**Re: Uniform design**