this is perfect for mounting the Pi filesystem :)
Calculating a record-breaking 31.4T digits of Pi with GCP
21–30 of 118 posts
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#22> March 14 (represented as 3/14 in many parts of the world) haha
The US and Philippines use month-day-year. The rest of the world doesn't. The most popular format is Day-Month-Year, followed by Year-Month-Day.
Yes. ISO chooses year-month-day, which puts largest component first and smallest last. This has the nice benefit that treating it as a string and doing alphanumerical sort matches the actual day sort. Ref. https://en.wikipedia.org/wiki/ISO_8601
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#23> March 14 (represented as 3/14 in many parts of the world) haha
I wanted to comment the same part, but I wanted to let them the benefit of the doubt, so I went to Wikipedia «date format by country» page [1], and summed up from the table how many people have "MD" vs "DM" in their date format:
DM -> 3392/5550 ~= 61.1% MD -> 2158/5550 ~= 38.9%
Note: I ignored both green and red regions that have both "DM" and "MD" in their format.
So it is definitively not the majority of people. Using the word "some" instead would have been better, but "Many" is not totally wrong… I guess.
[1] https://en.wikipedia.org/wiki/Date_format_by_country#Usage_m...
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#24Earlier quoted context omitted.
I guess it depends on your definition of "useful", but one potential way to use pi would be as a way to transmit compressed data incredibly efficiently. If you could find the data you want to transmit in pi somewhere you'd only need to transmit an offset and a length to send anything than can be represented numerically. The hard part would be finding what you want to send though... ;)
Offset and a length in Pi are not going to be shorter than original data to transmit.
Not necessarily. A double gets you pretty far into pi for a cost of just 8 bytes. A little bit of rounding, or checksumming, or other tomfoolery in principle should make it possible to reach absurdly far into pi for a byte or two more.
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#25How Many Decimals of Pi Do We Really Need? (NASA/JPL): https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimal...
In short 40 is already crazy too many digits for most if not all applications. Yet in the original article they say «Granted, most scientific applications don’t need π beyond a few hundred digits, …». Is there scientific applications where they would really need more than 40? Or is it just the author making some guess?
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#26Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#27How can you tell if the results are accurate?
This is explained in the second paragraph: > Yee independently verified the calculation using Bellard's formula[0] and BBP formula[1] [0] https://en.wikipedia.org/wiki/Bellard%27s_formula [1] https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%9...
Disappointed the Wikipedia article didn’t explain how in the world they arrived at that formula, why it even works. This type of stuff is pure magic to me.
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#28"31,415,926,535,897 to be exact, or π * 10^13"
Uhm no, you mean, approximately π * 10^13.
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#29Earlier quoted context omitted.
The US and Philippines use month-day-year. The rest of the world doesn't. The most popular format is Day-Month-Year, followed by Year-Month-Day.
Yes. ISO chooses year-month-day, which puts largest component first and smallest last. This has the nice benefit that treating it as a string and doing alphanumerical sort matches the actual day sort. Ref. https://en.wikipedia.org/wiki/ISO_8601
There are benefits to both little endian and big endian
Re: Calculating a record-breaking 31.4T digits of Pi with GCP
#30Earlier quoted context omitted.
Offset and a length in Pi are not going to be shorter than original data to transmit.
Not necessarily. A double gets you pretty far into pi for a cost of just 8 bytes. A little bit of rounding, or checksumming, or other tomfoolery in principle should make it possible to reach absurdly far into pi for a byte or two more.
If your offset is a million digits long you need to be sending more than a million digits of data to make it worthwhile, but the chance of your chosen million digits being available in that space is effectively zero. :)