Re: unexpected behaviour of Sum
- To: mathgroup at smc.vnet.net
- Subject: [mg126499] Re: unexpected behaviour of Sum
- From: Bob Hanlon <hanlonr357 at gmail.com>
- Date: Tue, 15 May 2012 04:53:36 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <201205140534.BAA27699@smc.vnet.net>
The problem is not with Sum it is with your definition of sod.
Note what happens with a symbolic input to sod:
sod[k]
k
This happens because IntegerDigits is not evaluated then Apply replaces its head with Plus and returns k.
Restrict the definition of sod to numeric input
sod[n_Integer] := ...
Bob Hanlon
On May 14, 2012, at 1:34 AM, perplexed <yudumbo at gmail.com> wrote:
> I do not want to say that this is a bug, however I did
> not find, in the Sum documentation, an explanation of this
> behaviour (v8.0.4)
>
> I defined an innocent function like
> sod[n_]:=Plus@@IntegerDigits[n]
> that compute the sum of the digits of a number.
> (I tried with other functions, so the culprit is not IntegerDigits)
>
> Then I compute two sums:
> Sum[sod[k],{k,10^6}] which gives 27000001 (ok)
> then
> Sum[sod[k],{k,1+10^6}] which gives 500001500001 (nonsense).
> then
> Sum[sod[k],{k,2,1+10^6}] which gives 27000002 (ok)
>
> so, it seems to me that Sum has a problem when the iterator
> works in a range greater than 10^6.
>
> Indeed, I made an experiment:
> I set L={}; and defined
> sod[n_]:=(AppendTo[L,n];Plus@@IntegerDigits[n])
> Then Sum[sod[k],{k,1+10^6}] still gives 500001500001
> and at the end L is equal to {k}, so it seems that
> Sum tried to do something symbolic (??).
>
> Is this a bug or a feature whose documentation I was not
> able to find? Say, is there an option to fix things ?
>
> Btw, using ParallelSum instead of Sum works fine (and faster).
> thanks
>
- References:
- unexpected behaviour of Sum
- From: perplexed <yudumbo@gmail.com>
- unexpected behaviour of Sum