Calculating constants to high precision

CRGreathouse
Science Advisor
Homework Helper
Messages
2,832
Reaction score
0
I'm trying to calculate some simple constants to high precision -- a few tens of millions of decimal places, maybe even a few hundred million. Are there any good programs out there that are fast at doing this? I'm using PARI/GP right now, but it's taking quadratic time to calculate ln(2), which means it would take a year or so to get 100M decimals, which exceeds my patience by about 11-1/2 months.

Any thoughts? If I have to program it myself, what's the best way to go about doing that -- in a program like pari, with a package like GMP, or straight-up in C or something similar?
 
Mathematics news on Phys.org
Actually i have a very efficient program that I would be happy to email to you if you gave me your address. Simple constants, 100m digits, at MOST an hour on a 3ghz computer.
 
Last edited:
Gib Z said:
Actually i have a very efficient program that I would be happy to email to you if you gave me your address. Simple constants, 100m digits, at MOST an hour on a 3ghz computer.
can you please mail that to me too. my e-mail address is murshid_islam@yahoo.com

thanks in advance. i have been trying to find such a program myself for some time now.
 
I PM'd you my email address.
 
K guys I've sent it, tell me how it goes.
 
Gib Z said:
K guys I've sent it, tell me how it goes.

I got it, thanks.

I'm not sure if it's correct, though. I'm having trouble figuring it out -- when I compared it to a trusted value of ln(2) from my hard drive (generated by pari), the two matched for the first 1,000,005 decimal places but differed thereafter. Wha...?

Also, when I searched for the section that differed between the two (starting 23172815271166), I found it in my 'trusted' file of pi. It starts at 1,000,006 in the qpi version but 2,000,016 in the pari version. This is a very unusual error and I can't figure it out. I'm especially confused by the repetition and the roundness of the numbers.

Further, http://www.research.att.com/~njas/sequences/A098289 seems to back up the pari version, as 2518028 appears in the position predicted by A098289(20) in the pari version but 4,000,000 off in the qpi version. I'm a bit confused.
 
Last edited by a moderator:
hmm...im actually not so sure about this, I never noticed...I merely used the program as a benchmark tool for my computer, not for the actual digits...Im sorry about the trouble then...maybe you could try the computation with different methods? instead of the default chudnovsky, try machin, borwein or ramanujan, theyre quite reliable.
 
Gib Z said:
hmm...im actually not so sure about this, I never noticed...I merely used the program as a benchmark tool for my computer, not for the actual digits...Im sorry about the trouble then...maybe you could try the computation with different methods? instead of the default chudnovsky, try machin, borwein or ramanujan, theyre quite reliable.

I'll look into it. I wonder if it might be a problem in the postprocessing, though, rather than in the calculation itself.
 
Back
Top