Mathematica Student Edition
Mathematica Home Edition
Computable Document Format (CDF)
Aerospace Engineering & Defense
Biotechnology & Medicine
Finance, Statistics & Business Analysis
Financial Engineering & Mathematics
Financial Risk Management
Software Engineering & Content Delivery
Authoring & Publishing
Social & Behavioral Sciences
Design, Arts & Entertainment
Game Design, Special Effects & Generative Art
STEM Education Initiative
Community & Technical College Education
Primary & Secondary Education
Computable Document Format (CDF)
High-Performance & Parallel Computing (HPC)
See Also: Technology Guide
Other Ways to Buy
Volume & Site Licensing
Does My Site Have a License?
Wolfram User Portal
About Wolfram Research
Stephen Wolfram's Home Page
Wolfram Functions Site
More Info >>
Mark as an Answer
A replacement for IntegerDigits: computing Sloane OEIS A229024 sequence
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
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
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
introduces more than a billion
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
in the interim? I thought to use
results in the identical incorrect value as before.
Which version were you using and on what platform? With version 9.0.1, I get
The number of trailing zeros is as expected:
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
consumes most of that RAM (I do have other stuff running in the background). The fact that you would consider doing a
on top of that suggests that you have at least twice as much RAM and points to the likelihood that my sporadic
misbehavior is the result of a system memory constraint.
Iliang: What is your $MaxNumber?
182616009! (* Overflow *)
$MaxNumber (* 1.233433712981650*10^323228458 *)
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
, 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
After looking at that link, I thought to try just breaking up my number into two parts and doing the sum on each:
In:= ds[n_] := Total[IntegerDigits[n]]
In:= f = 182616009; z = 0; c = 1; While[d = Floor[f/5^c]; d > 0, z = z + d; c++]; g = f!/10^z;
In:= a = Quotient[g, 10^714000000]; b = Mod[g, 10^714000000]; ds[a] + ds[b]
It worked! Thank you for your help.
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.
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.
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.
I have now done 400
sums in 10.9
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.