Calculating constants to high precision

Click For Summary

Discussion Overview

The discussion revolves around the calculation of mathematical constants to high precision, specifically targeting the computation of constants like ln(2) to tens or hundreds of millions of decimal places. Participants explore various software options and programming approaches to achieve this goal efficiently.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant is using PARI/GP for high-precision calculations but finds it inefficient for computing ln(2) at the desired precision.
  • Another participant claims to have an efficient program that can compute 100 million digits in about an hour on a 3GHz computer and offers to share it.
  • There is a request for the program from another participant who has been searching for a similar solution.
  • After receiving the program, one participant reports discrepancies between the computed value of ln(2) and a trusted value, noting that they match for the first million digits but diverge thereafter.
  • This participant expresses confusion over the nature of the error, particularly regarding the repetition and roundness of the numbers in the results.
  • Another participant suggests that the discrepancies might be due to the method used for computation and recommends trying different algorithms such as Machin, Borwein, or Ramanujan.
  • There is speculation that the issue might lie in postprocessing rather than the calculation itself.

Areas of Agreement / Disagreement

Participants express differing views on the reliability of the program shared and the accuracy of the results obtained. There is no consensus on the source of the discrepancies observed in the calculations.

Contextual Notes

Participants mention various computational methods and algorithms, but there is uncertainty regarding their effectiveness in this context. The discussion includes references to specific values and sequences, which may depend on definitions and assumptions not fully explored.

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?
 
Physics 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.
 

Similar threads

Replies
60
Views
5K
Replies
6
Views
2K
  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 0 ·
Replies
0
Views
4K
  • · Replies 7 ·
Replies
7
Views
7K
  • · Replies 0 ·
Replies
0
Views
3K
  • · Replies 10 ·
Replies
10
Views
3K
  • · Replies 12 ·
Replies
12
Views
3K
  • · Replies 0 ·
Replies
0
Views
2K
  • · Replies 14 ·
Replies
14
Views
2K