All Sites & Public Resources...
Products & Services
Data Science Platform
Personal Analytics for Facebook
Products for Education
Wolfram|Alpha for Mobile
Course Assistant Apps
Paid Project Support
All Products & Services »
Revolutionary knowledge-based programming language.
Central infrastructure for Wolfram's cloud products & services.
Technology-enabling science of the computational universe.
Computable Document Format
Computation-powered interactive documents.
Software engine implementing the Wolfram Language.
Wolfram Natural Language Understanding System
Knowledge-based broadly deployed natural language.
Wolfram Data Framework
Semantic framework for real-world data.
Wolfram Universal Deployment System
Instant deployment across cloud, desktop, mobile, and more.
Curated computable knowledge powering Wolfram|Alpha.
All Technologies »
Aerospace & Defense
All Solutions for Education
Web & Software
Authoring & Publishing
Finance, Statistics & Business Analysis
Financial Risk Management
Internet of Things
All Solutions »
Support & Learning
Find an Answer
Ask for Help
Post a Question
Videos & Screencasts
Conferences & Seminars
All Support & Learning »
Work with Us
A New Kind of Science
Wolfram + Raspberry Pi
Wolfram Innovator Awards
All Company »
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.
Be respectful. Review our
to understand your role and responsibilities.
Data Science Platform
Volume & Site Licensing
Wolfram Language Documentation
Connected Devices Project
Wolfram + Raspberry Pi
© 2015 Wolfram. All rights reserved.
Learn how »