8

I've defined a function that computes the sum of the base-b digits of n:

DigitSum[n_, b_] := Total[IntegerDigits[n, b]]

Then I defined a function that computes the sum of the base-b digits of all of the integers up to x:

CumDigitSum[x_, b_] := Sum[DigitSum[n, b], {n, 1, x}]

Using these functions, I get

CumDigitSum[1000000,10]=27000001

which is correct. But then for larger inputs I get nonsense like

CumDigitSum[1000001,10]=500011500011

If I work in a different base, the same thing happens: at exactly 1000001, Mathematica begins computing the sum incorrectly. If I bypass my user-defined functions and just write what I mean, I get the correct answer:

Sum[Total[IntegerDigits[n, 10]], {n, 1, 1000001}] = 27000003

Any idea what could be happening here?

Corey
  • 183
  • 3

2 Answers2

8

If you wish to compute the correct values using the method you have chosen you could specify Method -> "Procedural" for Sum:

CumDigitSum[x_, b_] := Sum[DigitSum[n, b], {n, 1, x}, Method -> "Procedural"]

CumDigitSum[1000001, 10]

27000003

However, the problem comes form the fact that Sum attempts to speed the calculation by finding a symbolic equivalent. Let's see what your DigitSum returns with symbolic input:

DigitSum[n, b]

b + n

That's clearly not correct generally! Why does this happen? Mathematica functions often work on arbitrary expressions as well as lists, and that is the case with Total. First the IntegerDigits call remain unevaluated:

IntegerDigits[n, b]

IntegerDigits[n, b]

But then Total adds its arguments as though this were {n, b}:

IntegerDigits[n, b] // Total

b + n

To prevent this you can add a Condition or PatternTest as belisarius recommended in a comment above:

DigitSum[n_?NumericQ, b_] := Total[IntegerDigits[n, b]]

This will block Sum form finding a (false) symbolic equivalent thereby forcing it to use a procedural evaluation, even with your original CumDigitSum definition.

For this particular case it is somewhat cleaner to use Tr in place of Total as it will not sum the arguments of an arbitrary expression:

Tr[IntegerDigits[n, b]]

Tr[IntegerDigits[n, b]]

Therefore:

DigitSum[n_, b_] := Tr[IntegerDigits[n, b]]

By the way, it is not recommended to start user Symbol names with capital letters as these can conflict with built-in functions, now or later.

Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
6

[Not exactly an answer but possibly of interest and definitely too large for the margins..]

Another way to do this is to reverse the order of summation. That is to say, there is an implicit sum over integer digits with an outer sum over integers. One could, in a sense, sum over the integers in the inner loop, and over digits in the outer. Well, sort of. Anyway, it may help to motivate the approach below.

If you have a power p of b for your upper bound, then, ignoring the very last element, you notice that all digits appear the same number of times, and the total number of digits appearing is p times b^p. Since there are b possible digit values, this means every digit appears p*b^(p-1) times. Now total the digits and throw in that factor.

With this in hand it is not hard to decompose for arbitrary n.

cumDigitSum[0, b_] = 0;
cumDigitSum[n_, b_] := Module[
  {len = IntegerLength[n, b] - 1, dtot = Total[Range[b - 1]], 
   top = First[IntegerDigits[n, b]], res},
  res = dtot*b^(len - 1)*len;
  Sum[res + j*b^len, {j, 0, top - 1}] + top*(n - top*b^len + 1) + 
   cumDigitSum[n - top*b^len, b]
  ]

Here are some tests.

cumDigitSum[100000, 10]

(* Out[71]= 2250001 *)

cumDigitSum[2607407, 10]

(* Out[72]= 71381880 *)

They agree with what I get from the straight summation method.

Daniel Lichtblau
  • 58,970
  • 2
  • 101
  • 199