Message Boards Message Boards

1
|
17285 Views
|
8 Replies
|
9 Total Likes
View groups...
Share
Share this post:

A replacement for IntegerDigits: computing Sloane OEIS A229024 sequence

Hans Havermann, Glad Hobo Express
Posted 12 years ago
I am on a quest to determine the 13th term in Sloane's (OEIS) A229024, a sequence that I recently authored. This sequence is all about calculating Total[IntegerDigits[n!] for a reasonably large subset of contiguous n. For the 13th term, n is in the vicinity of 182623000, the factorial of which has more than 1.4*10^9 decimal digits. It takes some 20 minutes for Mathematica to return on my system the sum of the digits of one such n!, so it will take me many months to chart the roughly 15000 sums that I think need to be done. Unfortunately, I am finding that for a random, roughly-2% of the n that I try, Mathematica returns an erroneous result. For example, I get for Total[IntegerDigits[182616009!]] a value of 1600311191. I know that this sum is incorrect because it is not evenly divisible by 9. (It is also significantly smaller than the sum of digits for nearby n-factorial. It appears that IntegerDigits[182616009!] introduces more than a billion additional trailing zeros preceding the 45653996 trailing zeros that I expect.)  I've reported the bug to Wolfram in the hope that this will be fixed in some future version, assuming of course that it is not my system that is responsible. So what procedure can I use to get a correct value for Total[IntegerDigits[182616009!]] in the interim? I thought to use DigitCount[182616009!] but Total[RotateRight[DigitCount[182616009!]]*Range[0, 9]] results in the identical incorrect value as before.
POSTED BY: Hans Havermann
8 Replies
Sort By:
I have now done 400 IntegerDigits sums in 10.9 Mavericks without a single fail. In 10.8 I would have encountered about six incorrect results, so I'm reasonably convinced that what I had initially assumed was a Mathematica bug was in fact Mac OS misbehavior. I have now done over 2500 sums and my very early result is that the 13th term in Sloane's (OEIS) A229024 is less than or equal to 180. I had been considering purchasing the upcoming Mac Pro which would definitely help me speed things along but I'm worried that it won't accomodate more than 64GB RAM, which would be a serious negative for such a high-end machine.
POSTED BY: Hans Havermann
Yes, my original computation now works under Mavericks. I'll hold off saying that it's fixed until I've done several hundred more digit sums. Mac memory management (though seamless to the user) was already a pretty complex affair in 10.8, and 10.9 introduces some new tricks in that department. I was half-expecting things to get worse, not better.
POSTED BY: Hans Havermann
Hans, if you happen to upgrade your operating system to OS X 10.9 Mavericks, I would suggest that you try the original computation again. Based on some testing, I would expect it to work properly with 10.9.
POSTED BY: Ilian Gachevski
After looking at that link, I thought to try just breaking up my number into two parts and doing the sum on each:
In[1]:= ds[n_] := Total[IntegerDigits[n]]
In[2]:= f = 182616009; z = 0; c = 1; While[d = Floor[f/5^c]; d > 0, z = z + d; c++]; g = f!/10^z;

In[3]:= ds[g]
Out[3]= 1394899135

In[4]:= a = Quotient[g, 10^714000000]; b = Mod[g, 10^714000000]; ds[a] + ds[b]
Out[4]= 6226582986
It worked! Thank you for your help.

Addendum: It won't work every time. I've tried this now on some of the other factorials that I didn't get and it's hit or miss. I guess my procedure shifts the burden to two new numbers and if one of those is susceptible to this bug, you still get a wrong answer.
POSTED BY: Hans Havermann
Thank you for the information, today I have been able to reproduce this problem on a couple of OS X machines, and will contact the appropriate developers. Your feedback is much appreciated.

For a possible workaround in the meantime, perhaps you could try one of the approaches mentioned in this Mathematica SE thread, although I am afraid they are more likely to exhaust the available memory (yes, I did not worry much about Split, but that's only because the Linux server I used had 144 GB of RAM).

@Simon: There is a bit more headroom on a 64-bit machine. On my Linux box, $MaxNumber is
8.768126706828697*10^2711437152599256
POSTED BY: Ilian Gachevski
Simon Schmidt
Simon Schmidt
Posted 12 years ago
Iliang: What is your $MaxNumber?
182616009!  (* Overflow[] *)
$MaxNumber  (* 1.233433712981650*10^323228458 *)
POSTED BY: Simon Schmidt
I am using 9.0.1 as well, on a current generation iMac (OS 10.8.5) with 32GB RAM (which is the maximum possible). Just doing IntegerDigits consumes most of that RAM (I do have other stuff running in the background). The fact that you would consider doing a Split on top of that suggests that you have at least twice as much RAM and points to the likelihood that my sporadic IntegerDigits misbehavior is the result of a system memory constraint.
POSTED BY: Hans Havermann
Which version were you using and on what platform? With version 9.0.1, I get
In[1]:= Total[IntegerDigits[182616009!]]

Out[1]= 6226582986
The number of trailing zeros is as expected:
In[2]:= IntegerExponent[182616009!]

Out[2]= 45653996

In[3]:= Length[Last[Split[IntegerDigits[182616009!]]]]

Out[3]= 45653996
POSTED BY: Ilian Gachevski
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Tag limit exceeded
Note: Only the first five people you tag will receive an email notification; the other tagged names will appear as links to their profiles.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract