MathGroup Archive 2012

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: unexpected behaviour of Sum

  • To: mathgroup at
  • Subject: [mg126499] Re: unexpected behaviour of Sum
  • From: Bob Hanlon <hanlonr357 at>
  • Date: Tue, 15 May 2012 04:53:36 -0400 (EDT)
  • Delivered-to:
  • References: <>

The problem is not with Sum it is with your definition of sod.

Note what happens with a symbolic input to sod:



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