My roommate in college had, while in high school, gone for a Guinness World Record memorizing the number of digits in pi. He memorized them out to 800 or so, then discovered another had memorized it to thousands, so he gave up.
In college, he figured out how to write a program to compute an arbitrary number of the digits of Pi. I asked him how did he know it was correct? He said "just look at it. The digits are right!"
We were limited in the use of the campus PDP-10 by a CPU time allotment per semester. He was planning to blow his allotment computing pi, he figured he could compute it to 15,000 digits or so. At the end of the term, he fired it up to run overnight.
The PDP-10 crashed sometime in the early morning, and his allotment was used up and had no results! He just laughed and gave up the quest.
Later on, Caltech lifted the limits on PDP-10 usage. Which was a good thing, because Empire consumed a lot of CPU resources :-/
Guiness is not an "authentic" record-keeping organization, in that they largely don't attempt to maintain accurate records of "the most X" and "the fastest Y". Rather, their business model is primarily based on marketing and publicity stunts: a company makes a ridiculously large pizza or whatever, and pays a very large amount of money to have Guinness "verify" their record for biggest pizza. A Guinness world record is just Guinness's record; it's commonly different from the true world record.
Guinness claims that the IBM System/360 (1964) was the first computer to use integrated circuits. I've tried unsuccessfully to convince them that they are wrong. The Texas Instruments Semiconductor Network Computer (1961) was the first, a prototype system, followed by multiple aerospace computers earlier than the System/360. Moreover, the System/360 used hybrid SLT modules which weren't even integrated circuits, so it's not even a contender. Maybe you could argue that the System/360 was the first commercial, production computer to use high-density modular electronics, but that's a lot of extra adjectives.
Not to mention, being used as a whitewashing tool by autocrats across the Middle East and Central Asia (for no reason other than a dick measuring contest).
> Later on, Caltech lifted the limits on PDP-10 usage. Which was a good thing, because Empire consumed a lot of CPU resources :-/
Knowing Caltech, there's a 50:50 chance that PDP is still running somewhere, torturing some poor postdoc in the astrophysics department because no one wants to upgrade it or port some old numerical code to a modern architecture.
In the 2001 film "Swordfish", there was always a piece of dialogue that stood out to me where Hugh Jackman describes code for a computer worm he wrote in college as being hidden on a PDP-10 I.T.S. machine kept online for history's sake. It's shown and noted that his character went to Caltech.
It is saying something that this might be the most plausible part of the film.
Funny timing. I was just musing about a middle-school classmate who endeavored to calculate as far as she could by hand and thinking how dated the idea was an hour ago. This was in the 90s, so it’s not as though we didn’t have computers. They just hadn’t reached mass-adoption in households.
I went to RPI's summer program for high school students in the mid 80s. I was hand assembling and linking assembly for a PDP-11 in the computer lab for a class, and I struck up a conversation with the sys admin of the "big" VAX-11 machine. The load over the summer on the VAX was low, so he was using the whole VAX to calculate the digits of pi. When I asked him "Why?", he said he hated to waste all those cycles. I remember less about the technical details of what he was doing than I do about PDP-11 assembly language. And pi is 3.1415927..., right?
Now that I am reading Meagher on octrees, I kind of wish I had met him--I think he was there at the time. I did get a tour of the image lab, and remember the colorful monkey on a monitor.
This new pi value should land us on the precise nanometer on a planetary rock of a sun located some 18 trillion light years away.
More than good enough for a Star Trek transporter targeting system, provided that sufficient power can reach it and able to compensate for planetary orbital speed, orbital curvature, surface axial rate, as well same value set for its solar system pathway around its galaxy, and its galaxy pathway thru its eyewatery cornucopia of galaxies.
But it may not be good enough for precise calculation of field interaction within a large group of elementary particles of quantum physics. Thanks to Heisenburg’s Indeterminacy Principle (aka Uncertainty Principle).
It's a shame they don't mention why they use specifically 15 digits (because of doubles?). Would give some satisfaction to why the specific amount after the explanation.
I imagine that you'd want to use fixed-point arithmetic when it comes to these things, right? Floating-point numbers are good enough for a lot of things, but the precise thing they're bad at is dealing in high precision at multiple orders of magnitude, which feels like a thing NASA would kinda need.
>but the precise thing they're bad at is dealing in high precision at multiple orders of magnitude, which feels like a thing NASA would kinda need.
The precise thing they are good at is dealing with number in a wide range of magnitudes. Where as fixed point numbers can not be used if the magnitudes vary wildly.
You can only use fixed point arithmetic if you know that every intermediate calculation you make will take place in a specific range of precision. E.g. your base precision might be millimeters, so a 32 bit fixed point number is exact up to one millimeter, but can at maximum contain a distance of 2^32-1 millimeters, so around 4.3 billion millimeters. But again you have to keep in mind that this is the maximum value for every intermediate result. E.g. when calculating the distance between two point in 3D space you need a power of 3, so every value you calculate the power of needs to have a value of less than the third root of 4.3 billion.
This makes fixed point arithmetic very hard to correctly implement and requires a very deep analysis of the system, to make sure that that the arithmetic is correct.
A lot of the parameters that enter their equations are probably measurements, like the gravitational acceleration, properties of some material, and so on. The numerical solutions to their equations have an error that is at least that of the most unprecise parameter, which I can't imagine to be more than four significant digits, so doubles should provide plenty of precision. The error introduced by the numerical algorithms can be controlled. I don't see why you'd need fixed point arithmetic.
I guess the GP comment was discussing that, with this new measurement of pi, we now have enough precision (in pi) to reference a point this small on an object this far away. Once you account for all the other uncertainties in referencing that point, as you mentioned, all that precision in one dimension of the measurement is completely meaningless.
It still feels weird that you'd use an arithmetic with guaranteed imprecision in a field like this, but I can definitely see that, as long as you constrain the scales, it's more than enough.
They put in scheduled fix the course burns, as there's a lot of uncertainty outside the math - the fuel burns probably can't be controlled to 5 sig figs, for example. Also, although I have no idea if this matters, N-body orbital mechanics itself is a chaotic system, and there will be times when the math just won't tell you the answer. https://botsin.space/@ThreeBodyBot if you like to see a lot of examples of 3-body orbits. (maybe just in 2d, I'm not sure).
Probably not - 64 bit float pretty much has enough bits that it wouldn't be an issue even on the scale of the solar system. Even if it was it would be easier just to switch to 128 bit float than deal with fixed point.
For two operations the floating point error is unbounded. If it ever made sense to carefully analyze a fixed point system it is for manned space flight.
That isn't exactly true. Floating point error is only really unbounded if you hit a cancellation (ie subtracting two big numbers), which you can avoid by doing some algebra.
There is no generic algorithm to completely prevent cancelation. However, there are a lot of specific little ways you can do algebra to push it around so it doesn't hurt you badly (note that I said "avoid", not "prevent"). I would conjecture that the vast majority of numerical systems can be designed that way if you take the time to think about it.
>I would conjecture that the vast majority of numerical systems can be designed that way if you take the time to think about it.
Sometimes there are ways to mitigate this, sometimes there aren't. Sometimes you need to precondition, sometimes you need to rearrange, sometimes you need a different algorithm, sometimes you need to normalize, sometimes you need to use a different arithmetic and so on.
For solving linear systems alone, there are definitely thousands of papers dealing with the problems arising from this. For every single algorithm you write and for all data which comes into that algorithm, you need a careful analysis if you want to exclude the potential of significant numerical errors.
Your comment makes it seem like this is a small problem, where you can just look at an algorithm for a time and fix it, this is literally a hundred year research project in numerics.
> Sometimes there are ways to mitigate this, sometimes there aren't. Sometimes you need to precondition, sometimes you need to rearrange, sometimes you need a different algorithm, sometimes you need to normalize, sometimes you need to use a different arithmetic and so on.
> For solving linear systems alone, there are definitely thousands of papers dealing with the problems arising from this. For every single algorithm you write and for all data which comes into that algorithm, you need a careful analysis if you want to exclude the potential of significant numerical errors.
It sounds like we agree that cancellation is avoidable with some analysis, and there are hundreds of techniques you can use to deal with it, but mostly it's the ~5 you listed there. And as you suggest, I don't believe this is nearly as significant a problem in the general case as you think it is. A careful error analysis is possible if you care (and if ever you cared, it would be on a spacecraft), and far easier in floating point than in many other number systems, including fixed point number systems.
Numeric systems that truly fix cancellation are incredibly big and heavy, and cannot usually be used for real-time calculations in a generic form. Fixed point certainly doesn't fix cancellation - it introduces precision loss issues on every operation you do that causes a number to go down in magnitude. It is actually harder to design systems in fixed point that avoid massive precision losses than it is in floating point, and the error analysis is much more substantial.
>I don't believe this is nearly as significant a problem in the general case as you think it is.
My original comment was about manned space flight in particular. If your application is relatively generic I think it is completely okay, if you are aware of it and mitigate the most pressing issues.
>Numeric systems that truly fix cancellation are incredibly big and heavy, and cannot usually be used for real-time calculations in a generic form.
You can use interval arithmetic, which guarantees that you at least know when cancellation has occurred. Interval arithmetic is fast enough for real time, although it has its own significant drawbacks.
> It is actually harder to design systems in fixed point that avoid massive precision losses than it is in floating point, and the error analysis is much more substantial.
Absolutely. My point was, that a manned space craft, might just be the point to do it.
> My original comment was about manned space flight in particular. If your application is relatively generic I think it is completely okay, if you are aware of it and mitigate the most pressing issues.
Everything we have been talking about relates to space flight. In fact, with humans on board, you can afford to be a lot less precise, because they can work around most numerical issues by hand. The Apollo guidance computers, for example, were prone to occasional instances of gimbal lock and numerical instability, and the astronauts just fixed it.
> You can use interval arithmetic, which guarantees that you at least know when cancellation has occurred. Interval arithmetic is fast enough for real time, although it has its own significant drawbacks.
Interval arithmetic does not prevent cancellation. It's just two floating point calculations, both of which are actually less precise than the one you would do otherwise (you don't use default rounding for interval arithmetic, you round the bottom down and the top up). You do know when things have been canceled, but you know that in a floating point calculation anyway if you have done the error analysis.
My overall point here is that NASA isn't missing anything by using floating point instead of using other weird or exotic arithmetic systems. Double-precision floating point combined with a rudimentary error analysis and some algebra is good enough for pretty much everything, and you may not be able to do better at all with fixed point. Designing fixed point algorithms also depends on a very careful analysis of interval ranges and precisions, and often gets you nothing over just using "double", where the error analysis is easier anyway.
If you need to do better than double, there's also double-double arithmetic for your hard parts, which is a similar speed to interval arithmetic and doubles the precision you get beyond double.
Because if your algorithm contains an "-" and you don't have complete control over the inputs to both sides of that minus, you will have cancellation.
There is no general way to mitigate that, you can use numerically superior algorithms or screen your inputs, but these only help in specific cases. There is no general way to avoid this, every algorithm needs to be treated specifically.
Okay, so, in practice, we do know lots of things about the inputs. It may be impossible "in the general case," but engineering is done in the specific case. Anybody writing control software for spacecraft knows whether the mass of the moon or the spacecraft is larger, and can rearrange their equations accordingly.
Exact and precise are different ideas. In fixed point, all operations but division are exact. In fixed point, all operations have precision related to the magnitude of the numbers being operated on. You can have a 64-bit fixed point number system that gives you 16 bits of precision on most of your operations.
In floating point, almost every operator (other than subtraction) has precision of the full width of the mantissa minus 0.5 ULPs. All operators are not guaranteed to always be exact, but they are far more precise on average than equivalent operators in fixed point.
Cancellation isn't an issue of exactness, it's an issue of precision.
Sure, but errors for fixed point happen very differently to floating point errors.
E.g. (a-b)*c, which is the common example for cancellation, if a and b are very close, can have an unbounded error compared to the result in the real numbers, in floating point. Since all operations besides "/" are exact in fixed point, no error can be introduced by this operation in fixed point (if all operations are representable).
Claiming that fixed and floating point are suffering the same way is just wrong.
(a - b) in fixed point will have very low precision, too, and will generally be exact in floating point. The following multiplication by c may or may not be exact in floating point (or in fixed point, mind you - multiplication of two n bit numbers exactly needs 2n bits of precision, which I doubt you will give yourself in fixed point). The "unbounded" error comes in when a and b themselves are not precise, and you have that same precision problem in fixed point as you do in floating point.
For example, suppose your fixed point format is "the integers" and your floating point format has 6 significant digits: if you have real-valued a = 100000.5 and b = 100001.9,
both number systems will round a to 100001 and b to 100002. In both cases, (b - a) will be 1 while (b - a) should be 1.4 if done in the reals. That rounding problem exists in fixed point just as much as in floating point. In both systems, the operation that causes the cancellation is itself an exact calculation, but the issue is that it's not precise. Fixed point will just give you 1 in the register while floating point will add a bunch of spurious trailing zeros. Floating point can represent 1.4, though, while fixed point can't. If a and b were represented exactly (a = 100001 and b = 100002 in the reals), there would be no problem in either number system.
The only times that you get better cancellation behavior are when you have more precision to the initial results, which when comparing double precision float to 64-bit fixed point comes when your operands in fixed point have their MSB at the 53rd position or above. That only happens when your dynamic range is so deeply limited that you can't do much math.
When you are thinking about cancellation numerically, exact is a red herring. Precise is what you want to think about.
Missed in my other response: Double gives about double the precision, not 4 times, that of a single:
"The 53-bit significand precision gives from 15 to 17 significant decimal digits precision (2−53 ≈ 1.11 × 10−16). If a decimal string with at most 15 significant digits is converted to the IEEE 754 double-precision format, giving a normal number, and then converted back to a decimal string with the same number of digits" (from Wikipedia)
Something like spaceflight is subject to chaotic forces and unpredictable interactions, so having that many digits (more than 15 decimal) becomes negligible. (For example, a planetary force will probably vary by that much in ways models don't capture, like subtle tidal forces and subtle variations in its orbit, etc.). Navigation usually involves methods of measuring your position and adjusting course in theory needing much less precision.
Simulating physical systems to extremely high precision (e.g. more than double precision) in general seems pointless in most situations because of those effects.
Adding on to this - the physical characteristics of the spacecraft itself are also not machined to nearly 15 digits of tolerance, so these feedback systems are necessary even if the rest of the universe were perfectly modeled.
If a double had happened to give 14 significant figures the article would list the exact same "why" 14 is enough. I.e. the article explains why it's more than enough, it doesn't explain why it's the exact number of digits used.
Precisely why I said it'd be good if the article had answered that question. The value of X isn't happenstance in this case, the article just doesn't mention that.
That NASA article kind of misses the point. NASA uses 15 digits for pi because that's the default and it is enough accuracy for them. The interesting question is why is that the default. That goes back to the Intel 8087 chip, the floating-point coprocessor for the IBM PC. A double-precision real in the 8087 provided ~15 digits of accuracy, because that's the way Berkeley floating-point expert William Kahan designed its number representation. This representation was standardized and became the IEEE 754 floating point standard that almost everyone uses now.
By the way, the first Ariane 5 launch blew up because of floating point error, specifically an overflow when converting a 64-bit float to an int. So be careful with floats!
> NASA uses 15 digits for pi because that's the default and it is enough accuracy for them. The interesting question is why is that the default.
The general rule of thumb in numerical analysis is you need roughly twice the working precision as the output precision. Double-precision floating point has ~16 decimal digits of precision, which means the output should generally be good for ~8 decimal digits; with single-precision, you have ~7 decimal digits of working precision, or about ~3-4 decimal digits of output precision.
In other words, a 32-bit floating-point number doesn't leave with enough useful precision for many cases, whereas a 64-bit floating-point number is good for most use cases.
> That goes back to the Intel 8087 chip, the floating-point coprocessor for the IBM PC. A double-precision real in the 8087 provided ~15 digits of accuracy, because that's the way Berkeley floating-point expert William Kahan designed its number representation. This representation was standardized and became the IEEE 754 floating point standard that almost everyone uses now.
It predates 8087! VAX had 64-bit floats with similar precision to IEEE 754 double precision. There's probably even older uses of 64-ish-bit floating-point types, but my knowledge of computers in the 60's and 70's is pretty poor. I fully expect you'd see similar results on those computers, though: you need enough decimal digits for working precision, and word-sized floating point numbers are just too small to have enough.
The 8087 itself doesn't use double precision types, it uses 80-bit types internally, which have 64 bits of mantissa (or ~19 decimal digits), although the reason for the 80-bit type is primarily to get higher precision for intermediate results on implementing transcendental functions.
This is something I wish was captured in programming more often. The well-loved library academics swear by is https://github.com/SBECK-github/Math-SigFigs but I wish there was a built-in "scientific number" type in every language that could make it easy for everyone to use.
> A double-precision real in the 8087 provided ~15 digits of accuracy, because that's the way Berkeley floating-point expert William Kahan designed its number representation
Kahan was the co-architect of the 8087. Palmer (at Intel) hired Kahan as a consultant for the 8087 since Kahan was an expert on floating point. Kahan says: "Intel had decided they wanted really good arithmetic. I suggested that DEC VAX's floating-point be copied because it was very good for its time. But Intel wanted the `best' arithmetic. Palmer told me they expected to sell vast numbers of these co-processors, so `best' meant `best for a market much broader than anyone else contemplated' at that time. He and I put together feasible specifications for that `best' arithmetic." Kahan and Palmer were co-authors on various papers about the 8087 and then Kahan and others authored the IEEE 754 standard.
And Kahan's Turing award: "During a long and productive relationship with Intel he specified the design for its floating-point arithmetic on several chips starting with the 8087" https://amturing.acm.org/award_winners/kahan_1023746.cfm
I think you're missing the point. The 8087's double-precision limit of ~15 decimal digits wasn't arbitrary -- the purpose of that device was to perform practically useful computations, so that amount of precision was chosen by the designers as a reasonable engineering trade-off.
IOW, the likely reason for not storing more mantissa bits than that is someone involved in designing the 8087 determined that even NASA doesn't need more precision than that.
>- I wonder if this cast is always correct in C [ie.: math.h], no matter the datatype and/or the number base?
Floating point arithmetic is deterministic. As long as it is implemented as specified atan(1) has to give the floating point number which is the closest approximation to the real number pi/4 (in the current rounding mode), the multiplication by 4 means that precision can be lost and potentially your result is no longer the closest possible approximation to pi.
this isn't true. the standard only recommends correct rounding, but does not actually set any limits on acceptable error. also, no OS provided libm produces correctly rounded results for all inputs.
Page 507 for adherence to number formats. Page 517 for atan adhering to IEEE 754 specification for the functions defined therein, which guarantees best possible results for individual operations.
Any C implementation where atan gives a result which is inconsistent with IEEE 754 specification does not adhere to the standard.
> also, no OS provided libm produces correctly rounded results for all inputs.
Every IEEE 754 conforming library does adhere to the best possible rounding guarantee. If you have any evidence to the contrary that would be a disaster and should be reported to the vendor of that library ASAP.
Can you provide some function and some input which violates the IEEE 754 guarantee together with the specific library and version? Or are you just making stuff up?
In the interests of moving this discussion in a positive direction, the comment you're replying to is correct. IEEE 754 doesn't specify correct rounding except for a small subset of elementary functions. In the 1985 version, this was the core +, -, *, /, and sqrt, but it was updated to include a few of the other functions when they were added. arctan is one of those functions which is not always correctly rounded due to the tablemaker's dilemma. If you read the latest standard (2019), they actually cite some of the published literature giving specific worst case examples for functions like arctan.
Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent. Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic.
>arctan is one of those functions which is not always correctly rounded due to the tablemaker's dilemma.
But then it doesn't conform to the standard. It is pretty unambiguous on that point.
From Section 9.2:
"A conforming operation shall return results correctly rounded for the applicable rounding direction for all operands in its domain."
I do not see how two conforming implementations can differ in results.
>Using FMA vs separate multiplication and addition leads to different results in real programs, even though both methods are individually deterministic.
Obviously. I never claimed that the arithmetic was invariant under transformations which change floating point operations, but are equivalent for real numbers. That would be ridiculous.
Is there actually an example of two programs performing identical operations under the same environment that give different results where both implementations conform to the standard?
>Even beyond transcendental functions, 754 isn't deterministic in practice because implementations have choices that aren't always equivalent.
Could you give an example? Where are implementations allowed to differ? And are these cases relevant, in the sense that identical operations lead to differing results? Or do they just relate to error handling and signaling.
That section is recommended but not required for a conforming implementation:
> 9. Recommended operations
> Clause 5 completely specifies the operations required for all supported arithmetic formats. This clause specifies additional operations, recommended for all supported arithmetic formats.
>That section is recommended but not required for a conforming implementation:
Who cares? The C standard for math.h requires these functions to be present as specified. They are specified to round correctly, the C standard specifies them to be present as specified, therefore the C standard specifies them as present and correctly rounded. I literally quoted the relevant sections, there are no conforming C specification which give different results.
Any evidence whatsoever that this is caused by two differing implementations of tanh, which BOTH conform to the IEEE 754 standard?
Everyone is free to write their own tanh, it is totally irrelevant what numpy gives, unless there are calls to two standard confirming tanh function which for the same datatype produce different results.
> The C standard for math.h requires these functions to be present as specified. They are specified to round correctly, the C standard specifies them to be present as specified, therefore the C standard specifies them as present and correctly rounded. I literally quoted the relevant sections, there are no conforming C specification which give different results.
Forgive me, but I cannot see that in the document sections you point out. The closest I can see is F.10-3, on page 517, but my reading of that is that it only applies to the Special cases (i.e values in Section 9.2.1), not the full domain.
In fact, my reading of F.10-10 (page 518) suggests that a conforming implementation does not even have to honor the rounding mode.
I'm not aware of any libm implementations that will guarantee correct rounding across all inputs for all types. I'm aware of a few libm's that will guarantee that for floats (e.g. rlibm: https://people.cs.rutgers.edu/~sn349/rlibm/ ), but these are not common.
I don't particularly want to read the standard today to quote line and verse, but it's generally understood in the wider community that correct rounding is not required by 754 outside a small group of core functions where it's practically reasonable to implement. This includes everything from the 754 implementation in your CPU to compiler runtimes. Correct rounding is computationally infeasible without arbitrary precision arithmetic, which is what the major compilers use at compile time. If you're expecting it at any other time, I'm sorry to say that you'll always be disappointed.
I mean, maybe I am just an insane guy on the internet, but to me "correctly rounded", just sounds a bit different to "the implementor gets to decide, how many correct bits he wants to provide".
We're thankfully in a world these days where all the relevant implementations are sane and reliable for most real usage, but a couple decades back that was very much the practical reality. Intel's x87 instruction set was infamous for this. Transcendentals like fsin would sometimes have fewer than a dozen bits correct and worse, the documentation on it was straight up wrong until Bruce Dawson on the chrome team filed a bug report.
(in summary, llvm-libc correctly rounds all functions, as it's explicitly borrowing from one of the correctly-rounded efforts; of the other implementations, Intel's library usually gets the closest, but not always).
In binary floating point, 4.0 = 1.0×2^2, so the mantissa of the multiplicand will stay the same (being multiplied by 1.0) and the exponent will be incremented by 2. Scaling by exact integer powers of 2 preserves the relative accuracy of the input so long as you stay in range. The increase in absolute error is inherent to the limited number of mantissa bits and not introduced by any rounding from the multiplication; there are no additional bits.
This is about the approximation to pi not the approximation to float(atan(1))*4, it is exact (but irrelevant) for the later, for the former you loose two bits, so you have a 25% chance of correctly rounding towards pi.
This is why Star Trek transporters have “Heisenburg compensators”. Everyone knows that. And also that you have to disable them if you want to beam holographic objects off a holodeck.
I know it was a monster-of-the-week format, but this episode really stuck with me. Created sentient life to never be discussed again. Data is only special in that he has a physical body.
Stuck on a shelf somewhere, oblivious to the fact that it's in a simulated environment. It'd be an interesting Star Trek II type followup when someone finds the cube and plugs in a cable only to have Moriarty escape and find a mobile emitter prototype somewhere on the network.. but I digress..
In floating point arithmetic two consecutive operations can have an unbounded error. Just because the precision is good enough for one computation doesn't mean it is good enough for all computations.
You're also underestimating the accuracy by the absurd amount of roughly 10^202000000000000 ;)
You need ~ zero of the digits of the calculated pi to do OPs calculation.
[edit] My brains melting, I think I'm wrong and you are underestimating the underestimation of the accuracy by the absurd amount of roughly 10^42000000000000. OP is underestimating by 10^202000000000000.
Imagine I'm using pi = 3 (accuracy of 1 significant figure) that's an error of about 4.5% of π(pi), 3.1 is only 1.3% 3.14 only 0.05% with the error decreasing with each additional significant figure.
Imagine there's a circle with radius 1m and you've got a calculated bearing to it calculated using pi = 3 . In the worst case in 2 dimensions for every meter you walked you could be walking off to the side ~0.0225 meters (napkin maths) from where the circle really is, so it would only take the circle being ~45m away for you to walk right by it rather than through it. With pi =3.1 you're diverging ~0.0066m per meter so the circle would need to be ~152m away before there was a chance you'd miss it. 11 digits of pi gets you about 3 light years of walking before you had a chance of missing.
They were discussing (with a large degree of understatement,as discussed by others above) that this value of pi gives great precision in these kinds of calculations.
But why?
Serious question.
I'm sure something interesting/useful might come out of it, and even if it doesn't just go for it, but is there any mathematical truth that can be gleaned by calculating pi to more and more digits?
Not particularly, only thing I can think of is if we analysed it and saw there was some bias in the digits, but no one expects that (pi should be a 'normal number' [1]). I think they did it as a flex of their hardware.
Isn't there a non-zero chance that given an infinite number of digits, the probability of finding repeats of pi, each a bit longer, increases until a perfect, endless repeat of pi will eventually be found thus nullifying pi's own infinity?
No, because it would create a contradiction. If a "perfect, endless repeat of pi" were eventually found (say, starting at the nth digit), then you can construct a rational number (a fraction with an integer numerator and denominator) that precisely matches it. However, pi is provably irrational, meaning no such pair of integers exists. That produces a contradiction, so the initial assumption that a "perfect, endless repeat of pi" exists cannot be true.
Yes and that contradiction is already present in my premise which is the point. Pi, if an infinite stream of digits and with the prime characteristic it is normal/random, will, at some point include itself, by chance. Unless, not random...
This applies to every normal, "irrational" number, the name with which I massively agree, because the only way they can be not purely random suggests they are compressible further and so they have to be purely random, and thus... can't be.
It is a completely irrational concept, thinking rationally.
> Pi, if an infinite stream of digits and with the prime characteristic it is normal/random, will, at some point include itself, by chance.
What you are essentially saying is that pi = 3.14....pi...........
If that was the case, wouldn't it mean that the digits of pi are not countably infinite but instead is a continuum. So you wouldn't be able to put the digits of pi in one to one correspondence with natural numbers. But obviously we can so shouldn't our default be to assume our premise was wrong?
> It is a completely irrational concept, thinking rationally.
The belief that a normal number must eventually contain itself arises from extremely flawed thinking about probability. Like djkorchi mentioned above, if we knew pi = 3.14....pi..., that would mean pi = 3.14... + 10^n pi for some n, meaning (1 - 10^n) pi = 3.14... and pi = (3.14...) / (1 - 10^n), aka a rational number.
> The belief that a normal number must eventually contain itself arises from extremely flawed thinking about probability.
Yes. There is an issue with the premise as it leads to a contradiction.
> Like djkorchi mentioned above, if we knew pi = 3.14....pi..., that would mean pi = 3.14... + 10^n pi for some n, meaning (1 - 10^n) pi = 3.14... and pi = (3.14...) / (1 - 10^n), aka a rational number.
Yes. If pi = 3.14...pi ( pi repeats at the end ), then it is rational as the ending pi itself would contain an ending pi and it would repeat forever ( hence a rational number ). I thought the guy was talking about pi contain pi somewhere within itself.
pi = 3.14...pi... ( where the second ... represents an infinite series of numbers ). Then we would never reach the second set of ... and the digits of pi would not be enumerable.
So if pi cannot be contained within ( anywhere in the middle of pi ) and pi cannot be contained at the end, then pi must not contain pi.
> If that was the case, wouldn't it mean that the digits of pi are not countably infinite but instead is a continuum.
No; combining two countably infinite sets doesn't increase the cardinality of the result (because two is finite). Combining one finite set with one countably infinite set won't give you an uncountable result either. The digits would still be countably infinite.
Looking at this from another direction, it is literally true that, when x = 1/7, x = 0.142....x.... , but it is obviously not true that the decimal expansion of 1/7 contains uncountably many digits.
> Pi, if an infinite stream of digits and with the prime characteristic it is normal/random, will, at some point include itself, by chance.
A normal number would mean that every finite sequence of digits is contained within the number. It does not follow that the number contains every infinite sequence of digits.
In general, something that holds for all finite x does not necessarily hold for infinite x as well.
Exactly - and when you remove the assumptions, what's left?
Pi is assumed to be infinite, random, and normal. The point here is not these assumptions may be wrong. Underneath them may sit a greater point; that irrationality is defined in a contradictory way - which may be correct, or not, or, both.
Given proof Pi is infinite lay on irrationality, it is rather an important issue. Pi may not be infinite, and a great place to observe that may be Planck.
> A normal number would mean that every finite sequence of digits is contained within the number.
Is that true? I don't see how that could be true. The sequence 0-9 repeated infinitely is, by definition, a normal number (in that the distribution of digits is uniform)
...and yet nowhere in that sequence does "321" appear ...or "654" ...or "99"
There are an infinite number of combinations of digits that do not appear in that normal number I've just described. So, I don't think your statement is true.
> I don't see how that could be true. The sequence 0-9 repeated infinitely is, by definition, a normal number (in that the distribution of digits is uniform)
Well, your first problem is that you don't know the definition of a normal number. Your second problem is that this statement is clearly false.
Here's Wolfram Alpha:
> A normal number is an irrational number for which any finite pattern of numbers occurs with the expected limiting frequency in the expansion in a given base (or all bases). For example, for a normal decimal number, each digit 0-9 would be expected to occur 1/10 of the time, each pair of digits 00-99 would be expected to occur 1/100 of the time, etc. A number that is normal in base-b is often called b-normal.
Your "counterexample" is not a normal number in any sense, most obviously because it isn't irrational, but only slightly less obviously because, as you note yourself, the sequences "321", "654", and "99" do not ever appear.
> Your "counterexample" is not a normal number in any sense, most obviously because it isn't irrational, but only slightly less obviously because, as you note yourself, the sequences "321", "654", and "99" do not ever appear.
lol. Your counterargument is a tautology because it contains "the sequences "321", "654", and "99" do not ever appear."
It's like if you claim, "A has the property B" then I say, "based on this definition, I don't think A has property B"
Then you say, "if it doesn't have property B, then it's not A"
...okay, but my point is, the definition that I had (from wikipedia) doesn't imply B. So for you to say, "if it doesn't have B, then it's not A" is just circular.
Now, you can point out that the definition I got from wikipedia is different from the one you got from wolfram. That's fine. That's also true. And you can argue that the definition you used does indeed imply B.
But what you cannot do is use B as part of the definition, when that's the thing I'm asking you to demonstrate.
You: all christians are pro-life
Me: I don't see how that's true. Here's the definition of christianity. I don't see how it necessarily implies being against abortion.
You: your """"counterexample"""" (sarcastic quotes to show how smart I am) is obviously wrong because, as you note yourself, that person is pro-choice, therefore, not a christian.
^^^^^ do you see how this exchange inappropriately uses the thing you're being asked to prove, which is that christians are pro-life, as a component of the argument?
Again, it's totally cool if you fine a different definition of christian that explicitly requires they be pro-life. But given that I didn't use that definition, that doesn't make it the slam dunk you imagine.
> But given that I didn't use that definition, that doesn't make it the slam dunk you imagine.
You might have a better argument if there were more than one relevant definition of a normal number. As you should have read in the other responses to your comment, the definition given on wikipedia does not differ from the one given on Wolfram Alpha.
> And you can argue that the definition you used does indeed imply B.
Given that the implication of "B" is stated directly within the definition ("For example, ..."), this seemed unnecessary.
> but my point is, the definition that I had (from wikipedia) doesn't imply B. So for you to say, "if it doesn't have B, then it's not A" is just circular.
Look at it this way:
1. You provided a completely spurious definition, which you obviously did not get from wikipedia.
2. You provided a number satisfying your spurious definition, which - not being normal - didn't have the properties of a normal number.
3. I responded that you weren't using the definition of a normal number.
4. And I also responded that it's easy to see that the number you provided is not normal, because it doesn't have the properties that a normal number must have.
Try to identify the circular part of the argument.
And, consider whether it's cause for concern that you believe you got a definition of "normal number" from wikipedia when that definition of "normal number" is not available on wikipedia.
It depends on your definition of "normal number". You seem to be using what wikipedia[1] calls "simply normal", which is that every digit appears with equal probability.
What people usually call "normal number" is much stronger: a number is normal if, when you write it in any base b, every n-digit sequence appears with the same probability 1/b^n.
IIRC the property ‘each single digit has the same density’ is the definition for a ‘simply normal number’ (in a given base), while ‘each finite string of a particular length has the same density as all other strings of that length’ is the definition for a ‘normal number’ (in a given base). And then ‘normal in all bases’ is sometimes called ‘absolutely normal’, or just ‘normal’ without reference to a base.
The work was done by a team at "Storage Review", and the article talks a lot about how the were exercising the capabilities of their processor, memory, and storage architecture.
As pi never repeats itself, that also means that every piece of conceivable information (music, movies, texts) is in there, encoded. So as we have so many pieces of pi now, we could create a file sharing system that's not based on sharing the data, but the position of a piece of the file in pi. That would be kinda funny
> As pi never repeats itself, that also means that every piece of conceivable information (music, movies, texts) is in there, encoded.
This is true for normal numbers [1], but is definitely not true for all non-repeating (irrational) numbers. Pi has not been proven to be normal. There are many non-repeating numbers that are not normal, for example 0.101001000100001...
Storing the index into pi for a file would usually take something like as much space as just storing the file, and storing or calculating enough digits to use that index would be impossible with the technology of today (or even probably the next century).
It's conjectured to be normal isn't it? I know it hasn't been proven yet, and I cannot seem to find where I read this, but I thought there was at least statistical evidence indicating that it's probably normal.
The rational numbers make up "zero percent" of the real numbers. It's a little hard to properly explain without assuming a degree in math, since the proper way to treat this requires measure theoretic probability (formally, the rationals have measure zero in the reals for the "standard" measure).
The short version is that the size of the reals is a "bigger infinity" than the size of the rationals, so they effectively have 'zero weight'.
But then the original implication, "100% of real numbers are normal, so that's pretty strong statistical evidence", still doesn't make any sense, as it's essentially using "100%" to imply "strong statistical evidence" that the rationals don't exist, which obviously doesn't follow.
I got the impression that the comment was a bit tongue-in-cheek.
The joke lies in the fact that saying "100% of real numbers" isn't *technically* the same thing as saying "all real numbers", because there's not really a good way to define a meaning for "100%" that lets you exclude rational numbers (or any other countable subset of the reals) and get something other than 100%.
it was about half a joke. statistical evidence doesn't really exist for the type of problem since polynomialy computable numbers are countably infinite so you can't define a uniform distribution over then
The thinking is inspired by the Infinite Monkeys Theorem. Which does have an easy-to-understand mathematical proof (and the criticisms of said proof are more difficult to grasp).
Isn't it a property of infinity? If pi goes on infinitely without repeating itself, every possible combination of numbers appears somewhere in pi.
It's sort of like the idea that if the universe is infinitely big and mass and energy are randomly distributed throughout the universe, then an exact copy of you on an exact copy of Earth is out there somewhere.
This property of infinity has always fascinated me, so I'm very curious for where the logical fallacy might be.
Not necessarily. The number 1.01001000100001000001... never repeats itself, yet most other numbers can never be found in it.
A number that contains all other numbers infinitely many times (uniformly) would be called normal, but no one has managed to prove this for pi yet. In fact, no one even managed to prove that pi doesn't contain only 0s and 1s like the above after the X-th digit.
The fact you can't encode arbitrary data in a structured-but-irrational number doesn't mean you can't encode data in a 'random' irrational number.
The question is really 'Does every series of numbers of arbitrary finite length appear in pi?' I can't answer that because I'm not a mathematician, but I also can't dismiss it, because I'm not a mathematician. It sounds like a fair question to me.
>I can't answer that because I'm not a mathematician
So what? Mathematicians can't answer it either. It is an open question and because it is an open question claiming it is or isn't true makes no sense.
>The fact you can't encode arbitrary data in a structured-but-irrational number doesn't mean you can't encode data in a 'random' irrational number.
You can not encode data in a random number. If it is random you can not encode data in it, because it is random. I am not sure what you are saying here.
I demonstrated that numbers where the digits go on forever and never repeat exist, which don't contain every single possible substring of digits. Therefore we know that pi can either be such or a number or it is not, the answer to that is not known. Definitely it is not a property of pi being infinitely long and never repeating.
That's why I put random in quotes. Pi is not a random number. You can encode data in it eg find a place that matches your data and give people the offset. That's not very helpful for most things though.
just index on the number of ones. Ex 0.10110 there are two ones in a row, so reference those two ones to be the number two. For 00, flip it and refer to the same pair of ones.
That is totally missing the point. Of course for every number there is an encoding that contains all pieces of information.
That obviously applies to 0.00... = 0 as well, it contains 0, then 00, then 000 and so on. So every number and therefore every piece of information is contained in 0 as well, given the right encoding. Obviously if you can choose the encoding after choosing the number all number "contain" all information. That is very uninteresting though and totally misses the point.
Most physicists don't believe that infinity can actually exist in the universe.
Put another way, the program which searches those works of art in the digits of pi will never finish (for a sufficiently complex work of art). And if it never finishes, does it actually exist?
That's a completely different issue. Using math to solve physics problems deals with physical models. Models are imperfect and what kinds of math they use is completely separate from asking "does infinity exist in our actual universe".
To answer that question, you would have to dismiss with experimental evidence all models people can come up with that try to explain the universe without "infinities". It's neither completely clear what that would mean, nor whether it's even in principle possible to determine experimentally (it's also most likely completely irrelevant to any practical purpose).
It's not that shocking to me - you should try tutoring a class of mathematics undergrads! They make this class of error all the time. It's a "this sounds like it's obviously true, so the obvious reason must be right" kind of thing. Rigorous logic takes a lot of time to click for people.
feel free to prove me wrong. I never said it's efficient, the point is just that the information is out there. If pi has the following subnumbers 00, 01, 10, 11 in there, we can construct every perceivable data we can encode as binary. Even with 0 and 1. So we can construct a file by pointers to these four numbers. The bigger substrings we can match, the bigger the compression ratio. The set of pointers might even be way bigger than the file itself. It's nowhere near efficient or clever, but just entertaining
I don't think you can argue against IP because the way you arrange the pointers is IP itself, but still a funny thought experiment anyway
I'm not saying, that every piece of information is in there end to end, but that there are parts in there which can be used to construct it. I think I should've made the "encoded" part a bit more transparent haha. But I love the discussion that I kicked off!
There are many ways in which a number might not never repeat itself, but not contain all sequences (e.g. never use a specific digit). What you want is normal numbers and pi is not proven to be one (though probably it is).
you might find this to be pretty cool. It's similar to what you're describing. Whoever made it has an algorithm where you can look up "real" strings of text and it'll show you where in the library it exists. you can also just browse at random, but that doesn't really show you anything interesting (as you would expect given it's all random).
> every piece of conceivable information (music, movies, texts) is in there, encoded
Borges wrote a famous short story, “The Library of Babel,” about a library where:
“... each book contains four hundred ten pages; each page, forty lines; each line, approximately eighty black letters. There are also letters on the front cover of each book; these letters neither indicate nor prefigure what the pages inside will say.
“There are twenty-five orthographic symbols. That discovery enabled mankind, three hundred years ago, to formulate a general theory of the Library and thereby satisfactorily resolve the riddle that no conjecture had been able to divine—the formless and chaotic nature of virtually all books. . .
“Some five hundred years ago, the chief of one of the upper hexagons came across a book as jumbled as all the others, but containing almost two pages of homogeneous lines. He showed his find to a traveling decipherer, who told him the lines were written in Portuguese; others said it was Yiddish. Within the century experts had determined what the language actually was: a Samoyed-Lithuanian dialect of Guaraní, with inflections from classical Arabic. The content was also determined: the rudiments of combinatory analysis, illustrated with examples of endlessly repeating variations. These examples allowed a librarian of genius to discover the fundamental law of the Library. This philosopher observed that all books, however different from one another they might be, consist of identical elements: the space, the period, the comma, and the twenty-two letters of the alphabet. He also posited a fact which all travelers have since confirmed: In all the Library, there are no two identical books. From those incontrovertible premises, the librarian deduced that the Library is “total”—perfect, complete, and whole—and that its bookshelves contain all possible combinations of the twenty-two orthographic symbols (a number which, though unimaginably vast, is not infinite)—that is, all that is able to be expressed, in every language.”
I've done the (simple) math on this -- in fact I'm writing a short book on the philosophy of mathematics where it's of passing importance -- and the library contains some 26^1312000 books, which makes 202T look like a very small number.
So though everything you describe is encoded in Pi (assuming Pi is infinite and normal) we're a long, long way away from having useful things encoded therein...
Also, an infinite and normal Pi absolutely repeats itself, and in fact repeats itself infinitely many times.
I just submitted a sub-page of that site, which has some discussion that touches more on the layout of the library as described by Borges:
https://news.ycombinator.com/item?id=40970841
This is not necessarily true. Pi might not repeat but it could at some point - for example - not contain the digit 3 anymore (or something like that). It would never repeat, but still not have all conceivable information.
But the number 3 is there just because we decide to calculate digits in base 10. We could encode Pi in binary instead, and since it doesn't repeat it necessarily will never be a point where there will never be another 1 or a 0, right?
That's true - you can quite easily prove that an eventually constant sequence of decimals codes for a rational number.
But it's also true that pi may not contain every _possible_ sequence of decimals, no matter what base you pick. Like the Riemann hypothesis, it seems very likely and people have checked a lot of statistics, but nobody has proven it beyond a (mathematical) shadow of doubt.
Obviously, it was just an example to illustrate what a non-periodic number could look like that doesn’t contain all possible permutations. If the number never contains the digit 3 in base 10 it will also not contain all possible permutations in all other bases.
It would average the same size as the actual data. Treating the pi bit sequence as random bits, and ignoring overlap effects, the probability that a given n bit sequence is the one you want is 1/2^n, so you need to try on average 2^n sequences to find the one you want, so the index to find it is typically of length n, up to some second order effects having to do with expectation of a log not being the log of an expectation.
You need both index and length, I guess. If concatenating both value is not enough to gain sufficient size shrink, you can always prefix a "number of times still needed to recursively de-index (repeat,start-point-index,size) concatenated triplets", and repeat until you match a desired size or lower.
I don’t know if there would be any logical issue with this approach. The only logistical difficulty I can figure out is computing enough decimals and search the pattern in it, but I guess that such a voluminous pre-computed approximation can greatly help.
No invertible function can map every non-negative integer to a lower or equal non-negative integer (no perfect compression), but you can have functions that compress everything we care about at the cost of increasing the size of things we don't care about. So the recursive de-indexing strategy has to sometimes fail and increase the cost (once you account for storing the prefix).
> every piece of conceivable information (music, movies, texts) is in there, encoded.
So that means that if we give a roomful of infinite monkeys an infinite number of hand-cranked calculators and an infinite amount of time, they will, as they calculate an infinite number of digits of pi, also reproduce the complete works of Shakespeare et al.
Isn't 202TB (for comparison) way too small to contain every permutation of information? That filesize wouldn't even be able to store a film enthusiast's collection?
Well it all comes down to encoding, doesn't it. We can represent almost everything with just 0 and 1 as well, can't we? The description of that data is way bigger than the elements used to describe it of course.
The sad thing is that the index would take just as much space as the data itself, because in average you can expect to find a n-bit string at the 2^n position.
Assuming we are only interested in base 10 and that pi contains e means that at some point in the sequence of decimal digits of pi (3, 1, 4, 1, 5, 9, 2, ...) there is the sequence of decimal digits of e (2, 7, 1, 8, 2, 8, ...), then I believe that question is currently unanswered.
Pi would contain e if and only if there are positive integers n and m such that 10^n pi - m = e, or equivalently 10^n pi - e = m.
We generally don't know if combinations of e and pi of the form a pi + b e where a and b are algebraic are rational or not.
Even the simple pi + e is beyond current mathematics. All we've got there is that at least one of pi + e and pi e must be irrational. We know that because both pi and e are zeros of the polynomial (x-pi)(x-e) = x^2 - (pi+e)x + pi e. If both pi+e and pi e were rational then that polynomial would have rational coefficients, and the roots of a non-zero polynomial with rational coefficients are algebraic (that is in fact the definition of an algebraic number) and both pi and e are known to not be algebraic.
Do you mean in the computed 202T digits of Pi, on in in the infinite sequence of Pi digits? In case of the latter: s̶u̶r̶e̶, probably, if Pi is normal, any finite sequence of digits is contained somewhere in Pi, so it would contain (in encoded form) any closed formula and any program, book, or piece of music ever written.
E: As the comments have pointed out, this requires the conjecture that Pi is normal to be true, was has not been proven or disproven yet.
Have they empirically checked that there is no pattern reproduction or just going by the proof? I imagine since this is the largest we've calculated to you could also empirically check the proof to confirm accuracy.
How do they verify that because even if it’s as simple as addition, you may have hardware anomalies that appears, just look at divisions and floating points weirdness on certain hardware
There are techniques which allow you to, for instance, calculate the 'n'th digit of Pi in base 10 (or binary, or hex, etc.) These are generally more computationally/memory expensive than the techniques used to calculate as many digits of Pi as possible.
So, you run your big calculation to get all XXX trillion digits on one machine, and run a completely different calculation to check, say, 1000 of those digits. If all match it's a pretty convincing argument that the calculation is correct.
I've never understood why people have such a hard-on for the digits of pi.
I've met more than one pi braggart who expected me to marvel at their ability to recite digits, but couldn't answer 'what is pi though? Don't use numbers, use words'. And they just didn't know.
It's one of those weird domains we're people can possess deep knowledge and no understanding.
This reminds me I've been curious to know what Hackernews people walk around with. I memorized 18 digits of Pi in highschool that I still remember and sometimes use as a bad joke here and there. But curious how many digits people here walk around remembering, specially if you aren't into competitively doing it (which I found out later is a thing).
I memorised the sqrt of 2 in highschool to impress the teacher. The first 32 digits eventually became part of my passwords, but significantly reduced nowadays because I kept running into too many length restricted invalidations.
100 + a few now (since age ~15). I briefly knew 400, but didn't put in the practice to keep it (some sections of those later 100s are still there, but I can't access them as I'm missing some digits in between). It takes about 40min. to get 100 new digits into my head (just straight repetition, paying attention to the sounds and patterns in rhythmic groups). Keeping them long-term requires a lot of time spent on spaced repetition. I run through the first 100 digits just a few times a year now, and it's all still easily there.
I memorized and forgot 50 digits of Pi after doing some memory training game. Was a cool bar trick but ultimately lost my memory palace discipline. I might be able to pull out some percentage of accuracy if I focused but it feels fairly pointless.
Nice achievement but always a bit disappointing that those records are based on throwing more money at the problem, rather than new theoretical grounds, or software improvements (IIRC y-cruncher is not open source).
Anyone else thinking a few nodes of those servers with their drool-worthy 60TB ssds in a HA environment would be really really awesome to play with and run infra on so I could go back to not worrying about cloud spend and just focus on cool and fun stuff?
I guess they were sponsored by their hardware manufacturers, on the condition that they mentioned their name once for every trillionth digit of pi they computed.
I can understand that they have to mention them, but I think they’re overdoing it.
I know human curiosity is a big reason why we pursue hard things in life. But can anyone tell me why this specific problem has been pushed to such limits. What is the utility here?
202 trillion digits of pi. Maybe someday I will be able to use this exact calculation to do something useful. Just need 61TB of memory or disk space to store the constant
Are there well interesting formulas where PI is potentiated?
This would affect the importance of the precision of PI's digits if i understand correctly.
I was shopping for a storage array last year, and was impressed by the IBM FlashSystem, which can stuff about 1.8PB (raw) into a 4U enclosure using forty-eight 38.4TB FlashCore modules.
StorageReview's server is a different beast, but it's kind of amazing that it gets similar capacity in only 2U.
If we are all living in a simulation there may have been an extremely stressed cosmic sys admin racing to make sure we did not get into an overflow situation.
"Cosmic sys admin" can terminate any misbehaving "process" that consumes too many resources. Matrix will protect itself, even if it would take a murder!
The Planck length has no physical significance. It's just a unit of length, chosen for convenience as part of the system of Planck units.
The Planck scale is the scale of lengths/times/etc that are around 1 in Planck units. This happens to be the scale roughly around which the quantum effects of gravity become significant. Since we do not have an accepted quantum theory of gravity, it's therefore the scale at which we cease to have an accepted physical theory.
There is no evidence to suggest that space is discrete at that scale. It's just the scale at which we have no accepted theory, and AFAIK no evidence to evaluate such a theory.
> The Planck length has no physical significance
> There is no evidence to suggest that space is discrete at that scale
Bekenstein bound and "planckian discreteness".
Reality is most likely not composed of a regular tesselation of simple geometric shapes such as a cartesian voxel grid as that would introduce massive anisotropy. But, there is still theoretic evidence suggesting that spacetime is indeed discrete at the lowest level.
Interesting stuff, and thanks - I didn't know about the Bekenstein Bound. I was referring to empirical evidence, though. AFAICS these are theoretical musings that, while they have some validity as far as they apply to the predictions of existing established theories, have to be considered entirely speculative in the quantum gravity regime where we don't have an accepted theory to base such reasoning on.
That is going to be a though one, at least direct measurements are pretty much ruled out if you consider that the plank length is about a quadrillion (yes, really 10^15) times smaller than the classical electron radius.
So, we will have to settle for indirect evidence and theoretical results.
But the way semi-serious people kick the idea around, sure. Pony up. I don't think that my religious beliefs submit to rigor, either. But I'm not here pushing something labeled as "religious beliefs" as a "hypothesis", either.
By the same token, if someone wants to call it the "Simulation Belief" in a religious sense, then I will lay by my dish.
Written or printed out at 3 digits per centimeter, 202 trillion digits would make a string about 670 million kilometers long -- or about the distance between Earth and Jupiter.
The context you omitted explains what they meant by "largest known digit", but I guess you were trying to be funny?
> The largest known digit of Pi is 2, at position 202,112,290,000,000 (two hundred two trillion, one hundred twelve billion, two hundred ninety million).
In college, he figured out how to write a program to compute an arbitrary number of the digits of Pi. I asked him how did he know it was correct? He said "just look at it. The digits are right!"
We were limited in the use of the campus PDP-10 by a CPU time allotment per semester. He was planning to blow his allotment computing pi, he figured he could compute it to 15,000 digits or so. At the end of the term, he fired it up to run overnight.
The PDP-10 crashed sometime in the early morning, and his allotment was used up and had no results! He just laughed and gave up the quest.
Later on, Caltech lifted the limits on PDP-10 usage. Which was a good thing, because Empire consumed a lot of CPU resources :-/