12.1T Digits of Pi | Hacker News Reader

12.1T Digits of Pi

numberworld.org

72 pointsrocky113825 comments

From 2013. The current record is 22.4 trillion digits from 2016:

https://pi2e.ch/blog/2016/11/11/hitting-the-target/

I used to be interested a lot in these topics (Mainly Pi and Mersenne Primes) back when cloud was not yet a thing and HPC meant building or renting large clusters. Got me into a lot of fun Beowulf cluster stuff which was super fun. Then also all the coding and tuning and fun algorithms.

An interesting story, though a lot of the details I have forgotten by now, I remember back in that time the race was on to get like 1T or something like that digits and there was a Japanese guy that built some sort of super rig for $10-20k at the time and got to 1T only to be beaten by Yahoo to 5T in like a couple weeks from there. There I saw the future of computing in large IT companies having the infrastructure to host large clusters cheaply which were dominated until then by supercomputers and research institutions. Might have gotten some details wrong as it's been like 10 years since then but the idea still stands.

Ah, I so long for the days of trying to make simple things like finding primes or digits of pi run fast. I remember making a lazy sieve of Eratosthenes that gave you the first 120 million or so primes in 6s using chez scheme. I later did the same kind of lazy construct for pi digits.

It actually taught me a lot about memory access and reasoning about speed, and also a lot about small things that are beneficial for speed.

12T digits of pi is mind-blowing, and in that short amount of time on pretty standard hardware.

One digit in base 10 uses log_2(10) = 3.322 bits. 12.1 trillion is 12.1×10^12, so that many decimal digits uses 40.195 × 10^12 bits = 5.024 × 10^12 bytes = 5.024 TB, if it is represented in the most compact form. But in the article they claimed "9.20 TiB of disk was needed to store the compressed digit output", which is about double of that.

According to the article the space intensive part was "60.2 TiB of disk was needed to perform the computation.". My guess is they weren't too worried with an optimal proprietary encoding of the final number, rather they simply lightly compressed the text output you see at the beginning of the article allowing easier consumption of the result. That text output seems to be ~3.6x less efficient.

I.e. nobody claimed optimal compression

The notion of optimal compression is nonsense anyway. Here is even more digits of pi, compressed to fit into this comment:

Decompression may take some work.

To calculate the circumference of our Universe with the accuracy od Planck length we only need some 60 or 70 digits of Pi. NASA uses 15 digits to send stuff to space. Calculating 22T is an absolute, mindboggling waste of time. Still impressive though! ;)

I guess it helps to bring forward the heat death of the universe, though why that might be a good thing defeats me.

Does parallelization work on this problem? I vaguely remember you can compute nth digit of Pi (not sure in what bases though) without computing the previous ones but this doesn't mean that an efficient parallel algorithm exists.

I wondered the same, according to the site its not possible to parallelize:

http://www.numberworld.org/y-cruncher/faq.html#distributed

The nth digit type computations are too slow.

“There exist algorithms like BBP to directly compute arbitrary binary digits without the memory cost of computing all the digits before it. These are called "digit-extraction" algorithms. However, these algorithms require roughly O(N*log(N)) time to compute a small number of digits at offset N. Using this approach to compute all the digits from 1 to N will result in a quadratic run-time algorithm. This alone makes it unsuitable for large N.”

What would it be the most repeating digit and at what position? Just curious.

You might have fun with this search engine:

http://www.angio.net/pi/

I won't prove this here: for any digit, there exists an arbitrarily long sequence of the same digit repeating somewhere within infinite decimal expansion of Pi. Further, this happens infinitely throughout the expansion. Thus, when dealing with Pi exactly, this question does not have an answer.

However, since we're dealing with such a limited representation of only a few trillion digits, this may have an answer...

Edit: as @nightcracker points out, this is conjecture. It is not currently know as to whether or not Pi has that property. (I could have sworn I read a proof years back). Thanks for the correction. With that said, it's not know as to whether or not this question has an answer.

You won't prove this here because you do not have a proof. What you claim is in fact a conjecture and is not known to current day mathematics.

We don't know. I bet you could win some math price money if you proved PI had some sort of statistical structure.

"The digits" in Pi will not give you relevant information.

The universe doesn't care about the base of our numbering system, so if our system was octal the answer would be totally different and equally irrelevant.

If there is a fundamental numbering system, then it's binary, but I don't think it makes much sense to analize the binary (floating point?) representation of Pi.

That's why I like continued fractions :)

A link in the article is dead: http://piworld.calico.jp/estart.html

Archived in 2015: https://web.archive.org/web/20150503034020/http://piworld.ca...

For the very naive, I assume FP math is not used in evaluating such constants. What then is in a toolkit used for such long decimals?

For the 12.1*10^12 calculation the refernced web site says: Hudnovsky algorithm [1] for the calculation, Bellard BBP formula for verification. Implementation in the programm y-cruncher "A Multi-Threaded Pi-Programy-chruncher" [3] For the math see [4] also.

[1] https://en.wikipedia.org/wiki/Chudnovsky_algorithm

[2] https://en.wikipedia.org/wiki/Bellard%27s_formula

[3] http://www.numberworld.org/y-cruncher/

[4] http://www.numberworld.org/misc_runs/pi-5t/details.html#form...

Check out the "Object Types" section of http://www.numberworld.org/ymp/v1.0/documentation/objects.ht...

The program has it's own types for arbitrary precision ints and floats.

For benchmarks like these, I'm curious how many CPU cycles it takes per digit. A hundred? A thousand?

If you assume 2.9 billion cycle per sec times 94 days divided by 12 trillion you get 2000 cycles per digit.

Reply on news.ycombinator.com