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
>

```

• Prev by Date: Load part of a package?
• Next by Date: Partly solved the problem of obtaining part of a package
• Previous by thread: Re: unexpected behaviour of Sum
• Next by thread: Re: unexpected behaviour of Sum