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


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


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?

  • 2
    $\begingroup$ It seems some symbolic processing mishap.If you define instead DigitSum[n_?NumericQ, b_] := Total[IntegerDigits[n, b]] it works (or at least it seems so) $\endgroup$ – Dr. belisarius Sep 8 '14 at 22:30
  • 1
    $\begingroup$ Yes, the default handling does not recognize that it needs to just sum in the pedestrian way. It will do what is expected if given Method -> "Procedural". $\endgroup$ – Daniel Lichtblau Sep 8 '14 at 22:40
  • $\begingroup$ @DanielLichtblau what is it doing by default? $\endgroup$ – Igor Rivin Sep 9 '14 at 3:59
  • $\begingroup$ @Igor Rivin I do not know for certain; presumably something symbolic along the lines mentioned by Mr. Wizard in his response. $\endgroup$ – Daniel Lichtblau Sep 9 '14 at 14:19
  • $\begingroup$ @DanielLichtblau Ah, I did not see Mr Wizard's explanation. Thanks! $\endgroup$ – Igor Rivin Sep 9 '14 at 16:34

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]

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


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.

  • $\begingroup$ Perfect! Thank you! $\endgroup$ – Corey Sep 8 '14 at 22:47
  • $\begingroup$ @Corey You're welcome, and thanks for the Accept. Don't miss my update regarding Tr as it can be handy. Carefully read its documentation however so that you don't misuse it. $\endgroup$ – Mr.Wizard Sep 8 '14 at 22:49
  • $\begingroup$ Nice. I should have mentioned the ?NumericQ possibility. (And I would have, if only I had thought of it.) $\endgroup$ – Daniel Lichtblau Sep 8 '14 at 22:58

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

  • 1
    $\begingroup$ Hi Daniel: I can't get your function to give the same results as Mr.Wizard's. The "6" in b^6 looks suspicious... $\endgroup$ – KennyColnago Sep 9 '14 at 0:49
  • $\begingroup$ @KennyColnago Thanks for pointing out the error. Edited and fixed. $\endgroup$ – Daniel Lichtblau Sep 9 '14 at 14:17
  • $\begingroup$ I really want to use your technique because it is creative thinking plus blinding speed; however, cumDigitSum[12,10] returns 49 ?? I've tried to understand your approach in order to suggest an edit to the code, but as yet cannot. $\endgroup$ – KennyColnago Sep 9 '14 at 20:24
  • $\begingroup$ @KennyColnago I think I have an off-by-one issue somewhere, probably whenever the final digit is not zero. $\endgroup$ – Daniel Lichtblau Sep 9 '14 at 20:41
  • $\begingroup$ @KennyColnago Edited again. And this time I tested against the other method. $\endgroup$ – Daniel Lichtblau Sep 9 '14 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.