For all you pi nerds:

[Leonhard]

Got the data, gimme a while to extract the number.

[Leonhard]

The 1,135,452,298,187th digit is 8, of course the digit in question was the 1,235,452,298th digit. Gimme a day or two.

[Roy]

The 1,135,452,298,187th digit is 8, of course the digit in question was the 1,235,452,298th digit. Gimme a day or two.

1,235,452,298,187th. Need more time?

But anyway, I admire your willingness to spend more time on Jorge's claim than he does.

Roy

[Leonhard]

1,235,452,298,187th. Need more time?

I'm downloading a chunk of the sequence, accidentally took down the digits between 1.135t and 1.136t, when I should have taken the chunk between 1.235t and 1.236t.

But anyway, I admire your willingness to spend more time on Jorge's claim than he does.

Got curious and I'm doing it for my own satisfaction. Doing a full in view proof on tweb might be interesting, though I don't know if I'll be able to get my hands on a computer good enough, however Jorge hasn't offered me any incentive so far.

[Jorge]

The algorithm used is well known and has already been proven to work. I could restate a proof here, but I don't see the point, especially since you're too dense to understand it.

"...too dense to understand it" ???
How in blazes would you know that?
Are you also psychic besides being stupid?

The calculation has been done and verified. If I had a computer with 8 Xeon processors, a dozen harddrives and 96gb of ram I could do something similar. If you had asked for a billionth digit, I could have it done soon enough even on the measly system I have access to. But I don't see what the utility of having my computer work out the whole length. Verifying it by parts would be sufficient, simple checking it up with the BBP-algorithm, as well as comparing it to earlier computations. The odds of this turning out to be wrong is unfathomably low. And since you're not bothered by anything bigger than 90% certainty, this should be more than enough for your standard of proof.

Speaking of "dense" -- you're too dense to realize that I was (1) kidding and (2) not kidding.
(1) 'Kidding' because I did not expect anyone to provide such a proof - not here.
(2) 'Not kidding' because an interesting problem in computational mathematics is how to
verify the results of exceedingly lengthy computational results. I trust that I do
not have to spell-out this problem to such a 'gifted intellect' as yourself.

Of course since you didn't specify whether you wanted the decimal number or hexadecimal number I could go and compute the hexadecimal number for you when I have the time. If you're interested.

My comment above answers your question.

See this is much more like the pathetic diploma-mill-phd clown that you like to be.

Awww ... and you had been doing relatively well. Now you've demonstrated
that you're in the same flock as Tiggy, Roy, et al. of similar Dodo plumage.
My, what a big flock you guys make.

BTW, just a thought : as you say, I'm a "pathetic diploma-mill-phd clown" and yet I
toy with you people with the same ease as a toddler plays with Silly Putty. If that
doesn't embarrass you then I guess nothing will. Bwahahahaha ....

Jorge

[Leonhard]

"...too dense to understand it" ???
How in blazes would you know that?

Because you're a moron Jorge. This is the consensus of the forum and I happen to be part of that consensus. You think you're the hardest hitting apologist on the block who dares say what the other don't. But you're all talk, and you know what Jorge, you're only hard around your mouth.

I was (1) kidding and (2) not kidding.

Covering all bases is a good way to escape criticism. Head I win, tails you lose.

(2) 'Not kidding' because an interesting problem in computational mathematics is how to
verify the results of exceedingly lengthy computational results.

There are ways of doing this without performing the job yourself. Here's an interesting toy problem, and its something other readers of this thread can think about: Alice says she has a way of counting a huge number of objects quickly, but Johnny is skeptical. He has an oak tree in his garden and he asks her to count the leaves. She does so and replies that there's 182.575 leaves and 112.333 buds on the tree. How can Johnny check if she really has the ability to count like that?

In the case of computing something like pi you can use a variety of techniques which makes the probability of the program messing up extremely unlikely. It has to be done carefully, but its not impossible and its standard practice for these things. You can start by checking it against previously tested results, assuming that those have been properly tested as well. After that you can use the discovery of a particular algorithm which computes an nth hexadecimal digit of pi without calculating all the preceding ones. The hexadecimal format is the format any computation of pi will be stored in before being converted to an ascii file. Its very fast if you want a small stretch of prime numbers. Its many, many times faster than computing the whole thing which is bogged down by memory bandwidth limitations. Believe it or not but computing pi is mainly slowed down by writing down and reloading various results, and most of the effort in these computing attempts is to minimize these bottlenecks by using clever tricks. But even then its mainly a memory bandwidth bottle necked calculation. Not so if you're only interest in a small stretch, and then this algorithm which is called BBP (there are others which may be even faster) for short is enormously fast. The point is that because of the nature of how pi is calculated if one mistake is made at some point all the later results will be thrown off. This was the case in a hand attempt to calculate pi by William Shanks in the eighteenth century. He calculated pi to the 707th decimal place, but he died happily unaware of the fact that he had made a mistake rendering all digits from the 528th place and onward wrong. It was only later when electronic computers had been developed that his error was discovered. But with the BBP-like algorithms in hand we can quickly calculate small stretches (which less than an hour instead of several weeks for a recomputation). If an error has been made then unless we've been so extraordinary unlucky that the error just so happened to produce the right digits in the area we're searching (odds: 1 in 16^n, where n is the number of digits in the small stretch) we have strong verification of the result.

Several ways of checking for errors have to be implemented, but its been verified that the last digits (and other stretches) of his computation match up to what the BBP algorithm (and its companions) will produce.

Awww ... and you had been doing relatively well. Now you've demonstrated
that you're in the same flock as Tiggy, Roy, et al. of similar Dodo plumage.
My, what a big flock you guys make.

BTW, just a thought : as you say, I'm a "pathetic diploma-mill-phd clown" and yet I
toy with you people with the same ease as a toddler plays with Silly Putty. If that
doesn't embarrass you then I guess nothing will. Bwahahahaha ....

Yes, yes Jorge, monkey away if that's what you want to do. Honk that clown horn and turn on the siren, let out a fart and slap a pie in your face.

[Jorge]

Because you're a moron Jorge. This is the consensus of the forum and I happen to be part of that consensus. You think you're the hardest hitting apologist on the block who dares say what the other don't. But you're all talk, and you know what Jorge, you're only hard around your mouth.

Your opinion and the consensus of a forum consisting mostly of Bible-distorters amounts to zilch!!

Covering all bases is a good way to escape criticism. Head I win, tails you lose.

Obviously you missed the point. Never mind ....................

There are ways of doing this without performing the job yourself. Here's an interesting toy problem, and its something other readers of this thread can think about: Alice says she has a way of counting a huge number of objects quickly, but Johnny is skeptical. He has an oak tree in his garden and he asks her to count the leaves. She does so and replies that there's 182.575 leaves and 112.333 buds on the tree. How can Johnny check if she really has the ability to count like that?

That was my point, Sherlock.

In the case of computing something like pi you can use a variety of techniques which makes the probability of the program messing up extremely unlikely. It has to be done carefully, but its not impossible and its standard practice for these things. You can start by checking it against previously tested results, assuming that those have been properly tested as well. After that you can use the discovery of a particular algorithm which computes an nth hexadecimal digit of pi without calculating all the preceding ones. The hexadecimal format is the format any computation of pi will be stored in before being converted to an ascii file. Its very fast if you want a small stretch of prime numbers. Its many, many times faster than computing the whole thing which is bogged down by memory bandwidth limitations. Believe it or not but computing pi is mainly slowed down by writing down and reloading various results, and most of the effort in these computing attempts is to minimize these bottlenecks by using clever tricks. But even then its mainly a memory bandwidth bottle necked calculation. Not so if you're only interest in a small stretch, and then this algorithm which is called BBP (there are others which may be even faster) for short is enormously fast. The point is that because of the nature of how pi is calculated if one mistake is made at some point all the later results will be thrown off. This was the case in a hand attempt to calculate pi by William Shanks in the eighteenth century. He calculated pi to the 707th decimal place, but he died happily unaware of the fact that he had made a mistake rendering all digits from the 528th place and onward wrong. It was only later when electronic computers had been developed that his error was discovered. But with the BBP-like algorithms in hand we can quickly calculate small stretches (which less than an hour instead of several weeks for a recomputation). If an error has been made then unless we've been so extraordinary unlucky that the error just so happened to produce the right digits in the area we're searching (odds: 1 in 16^n, where n is the number of digits in the small stretch) we have strong verification of the result.

Several ways of checking for errors have to be implemented, but its been verified that the last digits (and other stretches) of his computation match up to what the BBP algorithm (and its companions) will produce.

You make numerous logical errors above ... here's just one :

I already knew that, Einstein.

I didn't ask for "extremely unlikely", I was asking for mathematical certainty.
Do you know the difference?

I know that there are many techniques for reducing uncertainty and error.

But how can you verify FOR SURE that there isn't some cumulative or other
type of 'creeping' error in a computation that produces trillions of digits?
Comparing with other results (as you so naively suggest)? But you can't
do that when there are no other results (e.g., first time ever computations).

That problem, in case you don't know, is unsolved. The many techniques
yield very high confidence, but that is not the same as mathematical certainty.
Compare that with the fact that we can verify with absolute certainty that the
31st decimal digit of pi is a '5'. NOW do you get my point or do you need
more help from this lowly "pathetic diploma-mill-phd clown"? Bwahahahaha

Yes, yes Jorge, monkey away if that's what you want to do. Honk that
clown horn and turn on the siren, let out a fart and slap a pie in your face.

Yaaaaawwwwwwnnnnnnn

Jorge

[Catholicity]

and slap a pie in your face.

,
Leon, could we use banana cream?

[phank]

In fact, there is something called "proof of correctness" of computer algorithms, which is tedious but rigorous. Still, the probability of error of the algorithms and programs currently used is vanishingly small, whereas the probability that Jorge is incorrect is unity. Every time.

I'm happy if Jorge uses banana cream, but the probability of his actually hitting his face cannot be determined with absolute certainty.

[Roy]

In fact, there is something called "proof of correctness" of computer algorithms, which is tedious but rigorous.

And hardly used for even the most safety critical systems, since even if you prove the program is correct, you can't necessarily do the same for the compiler/interpreter or the underlying hardware. Consequently most critical systems use multiple independently implemented systems and in the rare cases where they produce different results, accept the majority verdict.

Roy

[Leonhard]

That was my point, Sherlock.

Then you can be the first one who can tell me how Johnny could verify Alice's abilities. If you don't have the answer by your next post I won't mind supplying what you can't figure out on your own. Its not a trick question, Johnny has a way of testing Alice without himself counting all the leaves and buds on the tree.

I didn't ask for "extremely unlikely", I was asking for mathematical certainty.
Do you know the difference?

And how would you know that a proof was correct Jorge? Read through all the steps carefully and do double checking with other peers? Even then there's a chance that somewhere there's a subtle error hiding that escaped attention, though the more eyes and error-checking used the less the probability of this happening. The proof of any computation of pi being correct is simple that the algorithms used converge to pi, and that they have been correctly implemented. The programs are complex, but not overwhelmingly so and they can be bug tested, which they have been.

But how can you verify FOR SURE that there isn't some cumulative or other
type of 'creeping' error in a computation that produces trillions of digits?
Comparing with other results (as you so naively suggest)? But you can't
do that when there are no other results (e.g., first time ever computations).

The BBP algorithm can quickly and efficiently be used to calculate small stretches of pi which can used to verify the results. Small stretches at any arbitary location say between the 1,244,513,153,111th and 1,244,514,153,113th decimal point. Any error would have a cumulative effect rendering the sequence after the error basically random. The odds of any random stretch of numbers accidentally matching a correct segment when doing an error check would be exponentially low depending on how long stretches that are being compared. And each time you run the error checking algorithm on a new segment the odds of the sequence being wrong would be decreased by a large factor.

That problem, in case you don't know, is unsolved. The many techniques
yield very high confidence, but that is not the same as mathematical certainty.

Very few things are known with absolute certainty, though I'd make an exception with your idiocy, Jorge. If this is correct then even mathematical proofs don't count as mathematical certainty rendering the concept meaningless. You're free to use this restricted definition of 'mathematical certainty' but mathematicians would shy away from it.

Compare that with the fact that we can verify with absolute certainty that the
31st decimal digit of pi is a '5'. NOW do you get my point or do you need
more help from this lowly "pathetic diploma-mill-phd clown"? Bwahahahaha

Did you know that we know the quadrillionth bit of pi in hexadecimals using the BBP algorithm? It happens to be 0 if you're curious. The same method can be used to verify just about any hexadecimal of pi. The hexadecimal format is what it will have immediately after computation, and that's the stage where its being verified. Calculating all the digits of pi using this method is terribly slow, but calculating small stretches is very fast.

Question: How do we verify with 'absolute certainty' that the 31st decimal place of pi is 5? I can write down an algorithm that extracts this result, and then you can question whether the algorithm is correct. I can write down a proof that the algorithm gives the right result and then you can question whether the proof is correct. I can carefully label out all the steps, and have other people (including yourself) verify them. Would that give 'absolute certainty'. No. It would still be possible that some error had been done somewhere. Its even possible that everytime someone has done a computation of pi people all over the world have made an error because of an accidental mental fluke, and that all our calculators have had a cosmic ray interfere with memory registers in just such a way as to produce '5' as the 31st digit of pi. Even assuming that the algorithms would have produced the right result. If there's even a shadow of a chance of error then you're not dealing with absolute certainty. It seems you're making a mistake in equivocating between absolute certainty and mathematical certainty.

Mathematical certainty, to me, merely means that we have analytic means of verifying a result to arbitrarily high certainty and that it has been checked to such a high degree that withholding assent is obscene. For example, a proof whose validity can be independently verified by mathematicians. And for this calculation of pi we have several methods: Verifying the implementations of the algorithms by studying the source code (though nobody has gotten the source code as of yet), checking it with the previous values, using the BBP-algorithm to check stretches and so forth.. We have the means to rule out even creative proposals that this two-man japanese team just copy pasted the past record and used the BBP-algorithm to calculate some small stretches here and there later used in the verification. All it takes is just to pick some areas at random, calculate them using BBP and check them. It would be extremely unlikely to hit the pre-calculated regions and not just random digits. I can do that, but I think you see the point.

Propose a way that this result could be wrong and slip past their proposed testing regime no more unlikely than a one in a billion chance of occurring.

[phank]

Very few things are known with absolute certainty, though I'd make an exception with your idiocy, Jorge...It would be extremely unlikely to hit the pre-calculated regions and not just random digits. I can do that, but I think you see the point.

I suspect I see a contradiction lurking here, and I'd set the odds of Jorge seeing the point at basically zero. The odds of Jorge not getting the point exceed the odds of the 31st digit being 5.

[Roy]

hexadecimal

Binary?

Roy

[Leonhard]

Binary?

Eh, that would also be in a hexadecimal format, you just need to take four bit chunks at a time. :3

[Sparko]

Pie is generally divisible by eight. so that would make it octal.