The mathmatical properties of Pi

[Kaonashi]

http://img.photobucket.com/albums/v395/Kaonashi/Blueberrypie.jpg :bhello: Pie Anyone!? I'm the new guy!

[beyelzu]

is mouth watering a mathematical property?





welcome to ff

:welcome:

[viscousmemories]

Good lookin' pie there, Kaonashi. :welcome:

[Petra]

Hello, hello!


The mathematical properties of pi are proportional to the pitch and length of a kitten's cry as it bakes.


Welcome! :cool:

[livius drusus]

Now that's what I call quality ingratiation. Tell me it's still warm and you've got a pint of vanilla bean ice cream around there somewhere, and you'll have bought me lock, stock and barrel.

Welcome to FF, Kaonashi, and thanks for the pi. :welcome2:

[Dingfod]

One mistake in the formulation though, the circumference should've included aluminum shielding so as to not burn the crust.
http://www.goldaskitchen.com/prodimg/NP3276.jpg

[Dingfod]

BTW, every good cook always has a Swiss Army knife nearby. It may not be able to multiply, but it is pretty handy at dividing.

[Shake]

The sum of the first 144 digits is 666!

Oh, welcome, Kaonashi!

[Goliath]

The sum of the first 144 digits is 666!

Oh, welcome, Kaonashi!

....:?

Do you mean the sum of 1, 2, 3, ..., 144? In that case, no, that sum is 10,440. If you mean honest-to-the-gods digits, then there are only ten of them (0 through 9).

So, ummmm...... :?

[Goliath]

http://img.photobucket.com/albums/v395/Kaonashi/Blueberrypie.jpg :bhello: Pie Anyone!? I'm the new guy!

:homdrool: Mmmmm.....Transcendentially delicious.....

[livius drusus]

I think he meant the first 144 digits of pie, Goliath.

[Goliath]

I think he meant the first 144 digits of pie, Goliath.

Ahhhh! Of course! LOL.... :doh:

/me looks up the first 144 digits of pi to check the computation.....

[pescifish]

I think he meant the first 144 digits of pie, Goliath.That's a lot of fingers to fit in that delicious pie! Jack Horner did his deed just using one of his thumbs.

Welcome to the board, Kaonashi! :wave:

[Goliath]

The sum of the first 144 digits is 666!


Yep, if you add the digits 1, 4, 1, 5, 9, 2, 6, .....9 that appear in the decimal expansion of pi as 3.1415926....9 (144 places after the decimal point), you indeed do get 666. That's very cool!

(and in case you're wondering: no, I didn't do that by hand...I programmed Mathematica to do it. :P ).

Oh, and welcome, Kaonashi! :)

[Skep]

What is the probability that the first n digits of the decimal expansion of any random irrational number will sum to 666?

[xorbie]

That would probably be horribly annoying to calculate.

[wade-w]

Statistics is not my strong point, but I suspect you need Bayes' Theorem for this one.

[SharonDee]

Gods, what a collection of geeks!

[nvexio]

looks like an awesome pie! and i'm all about me some pie! Welcome to this hell hole, friend! :)

[Goliath]

What is the probability that the first n digits of the decimal expansion of any random irrational number will sum to 666?

Hooboy!!! I'm not a Statistician, but let me try to take a crack at what might be involved in the answer to that...

First of all, we're going to need at least 74 digits (since adding up 9 seventy four times gives 666). So, if we choose a random irrational number x in (0,1) and if P(n) denotes the probability that the first n decimal places of x add up to 666, then P(n)=0 for 1<=n<=73, and P(74)=10^(-74) (since we must choose a 9 for each of the first 74 decimal places).

The sticky part is that there's no upper bound, since we can insert as many zeroes as we want....

Hmmmm what we're really looking at here is a subset of all possible partitions of a positive integer (in this case 666) such that each chunk of the partition is between 1 and 9. A partition of a positive integer m is the list of all possible combinations of smaller positive integers that add up to m. For example, the partitions of 6 are:

{6}, {5, 1}, {4, 2}, {4, 1, 1}, {3, 3}, {3, 2, 1}, {3, 1, 1, 1}, {2, 2, 2}, {2, 2, 1, 1}, {2, 1, 1, 1, 1}, {1, 1, 1, 1, 1, 1}

Hoooooboy...I told Mathematica to compute the number of partitions of 666, and it's still going...that means it's probably in the millions, if not larger...I have no idea how many of those only consist of 1, 2, 3, 4, 5, 6, 7, 8, and 9. However, let's pretend we have the set of those special partitions...let's call that set S (for lack of imagination).

So, given n >74, look at all partitions in S that have at most n elements. Then for each of these, account for all possible orderings, and if there are less than 74 elements in the particular partition, then look at all possible orderings when putting enough zeroes in-between to make n digits....hooboy...big numbers.

Well, that's how you'd calculate it (I think...as I said, I'm no statistician). As to what that probability is? No clue. A cursory MathSciNet search didn't turn up anything (but maybe because there's a fancy $6 word describing the process that we're trying to do that I don't know...).

Anyways, I'm rambling, so I'll end my rant here. I'm sure it was of no help. Oh well.

[Skep]

IANAM but here's my thinking:

Since zeroes have no effect on the sum nor does the size of n (with the exception that n >= 74) the number of zeroes (which must be finite) can be neglected. Regardless of the size of n, a point will be reached where the next non-zero digit makes the sum >= 666. Since only one of the nine non-zero digits will make the sum exactly 666, P(n) = 666 must be 1/9.

[nvexio]

jesus rupert christ iii...

[Goliath]

IANAM but here's my thinking:

Since zeroes have no effect on the sum nor does the size of n (with the exception that n >= 74) the number of zeroes (which must be finite) can be neglected. Regardless of the size of n, a point will be reached where the next non-zero digit makes the sum >= 666. Since only one of the nine non-zero digits will make the sum exactly 666, P(n) = 666 must be 1/9.

Ah, but you're not counting all the possible ways to get up to that point...let me illustrate with a smaller example. Let's say we want digits to add up to 30. If n=5, then here are just some of the possibilities for the first five decimal places:

.99930
.99390
.93990
.39990
.99903
.99093
.99039
.90993
.90939
.90399
.03999
.09399
.09939
.09993

....and those are just the possibilities with three 9's and a 3. So, These possibilities alone make up 14/10^6 of the possible choices.

And the number of zeroes of x (our chosen irrational number in (0,1)) cannot be neglected for a given n...in fact, the number of zeroes is crucial! If z denotes the number of zeroes in the first n decimal places of x, then if we pick our irrational number and we see that z=n (ie, the first n decimal places are all 0s), then we're outta luck.

It's late, I'm rambling, and I'm trying to look through huge stacks of papers for a specific citation on how a certain piece of terminology is used, so my brain may be a bit fried...sorry if that made no sense whatsoever.

[Skep]

jesus rupert christ iii...
http://skeptech.net/emotipad/cache/LMAO.gif

[Skep]

Goliath,

I have to apologize for my layman's lack of precision. I guess what I meant was: What is the probability that there exists an n >= 74 such that the first n digits of a random irrational number in the interval (0, 1) sum to 666?

[Goliath]

Goliath,

I have to apologize for my layman's lack of precision. I guess what I meant was: What is the probability that there exists an n >= 74 such that the first n digits of a random irrational number in the interval (0, 1) sum to 666.

Let me make sure that I've got this right...Given an irrational x in (0,1), you want to know the probability of existence of an n such that the first n decimal digits of x sum to 666, right?

[wade-w]

Skeptoid, you can ignore the zeros in the sum, but for your question, the zeros will most definitely affect the probability.

[Skep]

Goliath,

I have to apologize for my layman's lack of precision. I guess what I meant was: What is the probability that there exists an n >= 74 such that the first n digits of a random irrational number in the interval (0, 1) sum to 666.

Let me make sure that I've got this right...Given an irrational x in (0,1), you want to know the probability of existence of an n such that the first n decimal digits of x sum to 666, right?
Yes, that is correct.

[Goliath]

Goliath,

I have to apologize for my layman's lack of precision. I guess what I meant was: What is the probability that there exists an n >= 74 such that the first n digits of a random irrational number in the interval (0, 1) sum to 666.

Let me make sure that I've got this right...Given an irrational x in (0,1), you want to know the probability of existence of an n such that the first n decimal digits of x sum to 666, right?
Yes, that is correct.

Well, if we let P(n,x) denote this probability, then I can make the following obvious observation: If the decimal expansion of x consists of only zeroes and ones, then P(n,x)=1 for sufficiently large n (keep counting decimal places until you've added 666 ones...since x is irrational, you'll have to get to 666 ones eventually).

Okay, well, if you let S be all of the partitions of 666 consisting only of the numbers 1--9, then..well, if no partition in S has length <=n, then P(n,x)=0.

So, let's let T be the subset of S consisting of all partitions consisting only of the numbers 1--9 and which are of length at most n. If T is nonempty, then given some partition p in T with the length of p denoted by m_p (ie the "_p" indicates that p is a subscript), then the number of ways to put n-m_p zeroes between the numbers in p is nC(n-m_p) (the binomial coefficient "n choose n-m_p" ie n!/[(n-m_p)!(n-(n-m_p))!]=n!/[m!(n-m_p)!]) or, nCm_p. So, if we sum up all nCm_p where p ranges over all partitions in T, then this is the total number of ways to choose the first n digits of x such that P(n,x) is nonzero. Let's call this number...oh hell...I dunno... c (I'm running out of letters!!). Then if P(n,x) is nonzero, it equals c/10^n (the total number of ways to pick the first n decimal places of x to have the digits add up to 666 divided by the total number of choices for the first n decimal places of x).

Now, what that is in closed form? Not the slightest fucking clue...

By the way, this is easily generalizable from 666 to a general positive integer k.

[seebs]

OOooooh, Mathematica.

I probably still have the files and stuff for Mathematica for the NeXT, but I don't think any of the old NeXT hardware will run anymore. BLAH! I can't afford that toy, much though I want it.

[Goliath]

Wait a minute...on my way home from the office, I had a realization...

Skeptiod, do you mean:

1. For some positive integer n, what is the probability of finding a random irrational x in (0,1) such that the first n decimal digits of x add up to 666?

Or,

2. Given a fixed irrational x in (0,1), what is the probability of the existence of n such that the sum of the first n decimal digits of x is 666?

?

If you meant 1, then my answer above is correct (I think...).

If you meant 2, however, then that's a different kettle of fish. First, fix some irrational x in (0,1). Well, if n is less than the first decimal digit of x, then the probability is zero (that's the dumb case). Otherwise, start adding decimal digits of x until the sum is strictly within 10 of 666 and until the next decimal place is not a zero...let this decimal place be m.

Now, if we denote the ith decimal place of x by a_i, then:

0<=666-(a_1+a_2+a_3+....+a_m)<=9.

Now, look at a_(m+1). If a_1+a_2+...+a_m+a_(m+1)=666, yay!!!!! otherwise, booooo!!!! However, there can only be one choice of a_{m+1) amongst 1, 2, 3, 4, 5, 6, 7, 8 or 9 that will do the trick (remember, we're assuming that a_(m+1) is nonzero). Since we chose an arbitrary irrational x in (0,1) the probability of a_(m+1) equaling any digit from 1 to 9 has equal probability, whence the probability of finding an n is 1/9.

Actually, Skeptoid, I think this is what you were trying to say...I'm sorry for not understanding the problem...how embarrassing and humiliating. :doh: Sadly enough, I think I even stated problem 2 when I asked for clarification...and then went ahead and bungled forward with 1....the use of the word "random" probably threw me off (told ya I wasn't a statistician...).

I'm going to bed... :deepsigh:

[Goliath]

OOooooh, Mathematica.

I probably still have the files and stuff for Mathematica for the NeXT, but I don't think any of the old NeXT hardware will run anymore. BLAH! I can't afford that toy, much though I want it.

Yep, Mathematica isn't cheap....but for me it was free (and it only cost the taxpayers of SD a mere $895 :D ).

I've learned a fair amount about programming in Mathematica last year when I wrote* a program whose input is a negative (non-square) integer d and an element a+b*squareroot(d) in Z[squareroot(d)]. And the output includes all the irreducible factors of a+b*squareroot(d), along with all of the irreducible factorizations. :nerd:

* - well, okay...a fellow graduate student wrote a preliminary version of the program...I merely made it extremely more efficient. My program can do in about 2 seconds what his program took 2 hours to do.

[ceptimus]

I think 1/9 is wrong. I think the answer is 2/9 Here's my reasoning:

When summing a random string of digits, the average value that the sum increases by with each additional digit is:

0 + 0.1 + 0.2 + 0.3 + 0.4 + 0.5 + 0.6 + 0.7 + 0.8 + 0.9 = 4.5

Obviously the sum can only increase by an integer, but on average it will increase by 4.5, so the sum of 1000 random (base-10) digits I would expect to be about 4500.

Now as the sum starts from a known value (zero), there may be some interesting patterns to begin with. Eg. there is only a 1 in 9 chance (I think) of the sum reaching the value of '1', but by the time we get up to 666 these 'starting effects' should be negligible, so I say the chance of reaching 666 is 1 / 4.5, or 2/9

Edit to add: 666 / 4.5 is 148, so I'd expect 148 to be the commonest length for any string of random digits that sums to 666.

[wade-w]

Ummm, Ceptimus, the probability that you get any particular digit in the nth decimal place is 1/10. So if it takes n digits to get to the sum 666, the probability that the entire string of digits is in that order would be (1/10)^n. If the question is Goliath's 2) above, then this is the answer.

But if it's 1) then obviously, order does not matter here, so this isn't the actual answer; you'd have to calculate the number of permutations of that particular combination of digits, as Goliath illustrated before.

Or maybe not. Probability is very slippery, and even professional statisticians often have to stop nad think about a seemingly simple problem at times.

[seebs]

I wish they had a "hobbyist" version of Mathematica.

[pescifish]

There is probably a "student version". seebs, as an author you may be able to qualify for the educational version of major software packages. I don't know about Mathmatica, but, for example, the educational version of MATLAB went for $100 last time I looked into it (2.5 years ago).

[Goliath]

ceptimus,

The problem is that expected values are not probabilities.

[Corona688]

I'm going to try looking at this a different way...

We have n digits, the sum of which is 666. 666 is actually a pretty convenient number -- it's an exact multiple of 9. Since 666/9 = 74, the minimum possible n to get a sum of 666 would be 74 digits. There is only one way to get a sum of 666 from 74 digits -- all nines. So the probability of getting a sum of 666 in 74 digits is 1/10^74, also known as "pretty damn small".

Now to add another digit... Let's look at it this way -- assume 75 digits full of 9's, for a total of 666+9. We also have nine -1's that we can sprinkle anywhere we want to bring the sum back down to 666. We've got 75 choices for the first one, 75 choices for the second, etc etc. Multiply them all together and we have 75^9 ways to create a sum of 666 from 75 digits. Which means the probability of getting a sum of 666 with 75 digits is 75^9/10^75, or approximately 1/(8*10^59).

Adding another digit to this will be trickier, since there will be eighteen -1's to distribute among the 76 digits. For digits other than the first digit we can just borrow from previous ones, but the first digit has nowhere to borrow from. So I'll modify the situation a little.
The first digit is 1, and the next 75 digits are all 9's, for a sum of 676. We have eighteen -1's we can distribute anywhere among the last 75 digits, and eight +1's that we can plunk anywhere among all 76 digits to make up for the eight we left off the first digit. Multiply these possibilities together and we get (75^18)*(76^8) ways to create a sum of 666 in 76 digits, for a probability of ((75^18)*(76^8))/(10^76) of this sum being created in 76 digits. In more readable terms this is around 1/(6*10^28) -- better, but still really small.

Adding another digit works similarly. The first digit is two and the 76 digits after it are 9 for a sum of 677. We have twenty-seven -1's to distribute among the 76 digits and seven 1's to distribute among all 77 digits, for ((75^27)*(76^7))/10^77, or approximately 1/(6*10^14).

I don't see how to give an exact answer for the question of n digits, but I'll try to give a ballpark answer. The number of digits we need to exclude from distributing -1's among increases proportional to log10((n-74)*9), and the number of -1's to be distributed increases linearly as (n-74)*9. The number of extra 1's to be distributed among the digits also increases with log10((n-74)*9).

Let a = (n-74)*9

( ( (n - log10(a) )^a) * n^log10(a) ) / 10^n

is my best estimate of the probability of n digits of an irrational number having a sum of 666, for values n > 74.

[ceptimus]

Why not try an empirical approach? You can sum the digits of e, phi, pi-squared, and a load of other irrational numbers. Just use the square roots of all integers that aren't perfect squares, for example.

I bet my 2/9 figure is spot on. Anyone want to bet?

[Goliath]

Ummmm....no, that's still wrong, ceptimus. We can't sprinkle -1s...we can only sprinkle elements from the set {0,1,2,3,4,5,6,7,8,9}. Also, keep in mind that we're starting with a fixed x and trying to find n, not the other way around (that's the same mistake that I made).

[Corona688]

Ummmm....no, that's still wrong, ceptimus. We can't sprinkle -1s...we can only sprinkle elements from the set {0,1,2,3,4,5,6,7,8,9}. That wasn't ceptimus. :)

And sure we can sprinkle -1's, though by 'sprinkling' I mean 'adding'. Putting a -1 on the digit 9 will turn it into 8 and so forth -- it's just a different way of representing combinations of digits from the set {0,1,2,3,4,5,6,7,8,9}. My apologies if that was unclear.

The number of different ways we can distrubute all the -1's is the number of different ways the sum of 666 can be achieved. It becomes trickier when there's more than nine -1's to worry about, because then you have to worry about borrowing.

[Goliath]

That wasn't ceptimus. :)

Oops, sorry.



And sure we can sprinkle -1's, though by 'sprinkling' I mean 'adding'.



But the problem is that we can only choose digits from {0,1,2,3,4,5,6,7,8,9}, so while we can add -1s, we can't have a -1 as a digit.

[Corona688]

And sure we can sprinkle -1's, though by 'sprinkling' I mean 'adding'.But the problem is that we can only choose digits from {0,1,2,3,4,5,6,7,8,9}, so while we can add -1s, we can't have a -1 as a digit. That's not a problem, since I am not using -1's as digits. I am taking a string of all 9's and subtracting 1 from digits here and there to bring the sum of the digits down to 666.

I've just realized a major flaw in my methodology though. My original plan was to 'borrow' from previous digits if the sum went below zero, but that won't work. If borrowing in the traditional sense is done, the net effect is to add eight to the total, since the position of the decimal is meaningless to the sum; and if I borrow by only removing one from a previous digit, that means that different combinations might borrow from the same digit -- the combinations are no longer unique.

So my method only works for 75 digits. Damn.

[Goliath]

And sure we can sprinkle -1's, though by 'sprinkling' I mean 'adding'.But the problem is that we can only choose digits from {0,1,2,3,4,5,6,7,8,9}, so while we can add -1s, we can't have a -1 as a digit. That's not a problem, since I am not using -1's as digits. I am taking a string of all 9's and subtracting 1 from digits here and there to bring the sum of the digits down to 666.

I've just realized a major flaw in my methodology though. My original plan was to 'borrow' from previous digits if the sum went below zero, but that won't work. If borrowing in the traditional sense is done, the net effect is to add eight to the total, since the position of the decimal is meaningless to the sum; and if I borrow by only removing one from a previous digit, that means that different combinations might borrow from the same digit -- the combinations are no longer unique.

So my method only works for 75 digits. Damn.

Ah, okay, I understand now. And yeah, there are many combinations that you wouldn't be accounting for.

There's a statistician in my department...I'll ask him. It wouldn't surprise me if someone has already figured this out.

[xorbie]

As I said... really annoying ;)

Assuming I'm understanding the problem correctly, i.e. that given an irrational number N in (0,1), you want to know what the probably is that some n exists, where the sum of the first n digits of N is exactly x=666.

In order to do this, you can actually ignore all 0's, because they don't affect the existence of such an n, they just affect what it actually is.

Let Ax = The event that an n exists for some x..

Then P(Ax) = Sum{P(Bi)*P(Ax|Bi)} where Bi is the event that the first digit is i, i=1,2,..,9. P(Ax|Bi) is the probability of Ax occuring, given that Bi has occured.

Thus, P(Ax) = Sum{P(Bi)*P(Ax-i)}

I believe that, in theory, you can write an algorith that continues this process down. Not something I want to do right now, as I'm on the way about. Should be a start though.

[wade-w]

As I said... really annoying ;)

Assuming I'm understanding the problem correctly, i.e. that given an irrational number N in (0,1), you want to know what the probably is that some n exists, where the sum of the first n digits of N is exactly x=666.

In order to do this, you can actually ignore all 0's, because they don't affect the existence of such an n, they just affect what it actually is.

Let Ax = The event that an n exists for some x..

Then P(Ax) = Sum{P(Bi)*P(Ax|Bi)} where Bi is the event that the first digit is i, i=1,2,..,9. P(Ax|Bi) is the probability of Ax occuring, given that Bi has occured.

Thus, P(Ax) = Sum{P(Bi)*P(Ax-i)}

I believe that, in theory, you can write an algorith that continues this process down. Not something I want to do right now, as I'm on the way about. Should be a start though.

IOW, Bayes' Theorem.

[xorbie]

IOW, Bayes' Theorem.

I'm not sure about that... I thought Baye's Theorem was specifically that:
P(A|B) = P(B|A)*P(A)/P(B)

Derived from:

P(B|A) = P(A U B)/P(A)

P(A|B) = P(A U B)/P(B)

[Goliath]

As I said... really annoying ;)

Assuming I'm understanding the problem correctly, i.e. that given an irrational number N in (0,1), you want to know what the probably is that some n exists, where the sum of the first n digits of N is exactly x=666.

In order to do this, you can actually ignore all 0's, because they don't affect the existence of such an n, they just affect what it actually is.

Let Ax = The event that an n exists for some x..

Then P(Ax) = Sum{P(Bi)*P(Ax|Bi)} where Bi is the event that the first digit is i, i=1,2,..,9. P(Ax|Bi) is the probability of Ax occuring, given that Bi has occured.

Thus, P(Ax) = Sum{P(Bi)*P(Ax-i)}

I believe that, in theory, you can write an algorith that continues this process down. Not something I want to do right now, as I'm on the way about. Should be a start though.

Well, since we've fixed N (using your nomenclature), then precisely one of P(Bi) will be nonzero, so your equation collapses to P(Ai)=1*P(Ai|Bi) where we have a specific i with P(Bi)=1.

Unless I'm misunderstanding something...which is more than possible. I'm going to this straight from thinking about convex subgroups of a group of divisibility and multiplicative sets, so I could be misunderstanding...

[Dingfod]

What does any of that have to do with the price of beans in Pie-na? (http://www.cooks.com/rec/doc/0,162,150163-226192,00.html)

[xorbie]

As I said... really annoying ;)

Assuming I'm understanding the problem correctly, i.e. that given an irrational number N in (0,1), you want to know what the probably is that some n exists, where the sum of the first n digits of N is exactly x=666.

In order to do this, you can actually ignore all 0's, because they don't affect the existence of such an n, they just affect what it actually is.

Let Ax = The event that an n exists for some x..

Then P(Ax) = Sum{P(Bi)*P(Ax|Bi)} where Bi is the event that the first digit is i, i=1,2,..,9. P(Ax|Bi) is the probability of Ax occuring, given that Bi has occured.

Thus, P(Ax) = Sum{P(Bi)*P(Ax-i)}

I believe that, in theory, you can write an algorith that continues this process down. Not something I want to do right now, as I'm on the way about. Should be a start though.

Well, since we've fixed N (using your nomenclature), then precisely one of P(Bi) will be nonzero, so your equation collapses to P(Ai)=1*P(Ai|Bi) where we have a specific i with P(Bi)=1.

Unless I'm misunderstanding something...which is more than possible. I'm going to this straight from thinking about convex subgroups of a group of divisibility and multiplicative sets, so I could be misunderstanding...


Well, that seems like cheating to me, tantamount to saying "the probability of the Red Sox winning the world series is either 0 or 1."

IOW, I've interpreted the problem as being given an infinite number of digits, each of which is randomly chosen. If we already know what each digit is, then we can already figure out if an n exists simply by adding up the digits as we go along.

[Goliath]

IOW, I've interpreted the problem as being given an infinite number of digits, each of which is randomly chosen. If we already know what each digit is, then we can already figure out if an n exists simply by adding up the digits as we go along.

Ah, but we start by fixing x (the irrational number in (0,1)), so the digits of x are determined at the beginning...they no longer vary for the rest of the problem.

To address your analogy, since we've fixed the (2004) World Series champs as the Red Sox, the probability of the Red Sox being the 2004 World Series champs is 1.

On the other hand, if you let both x and n vary....eeeep! That would be even worse!

[ceptimus]

I wrote a PHP script to investigate this.

It takes the square roots of integers that are not perfect squares, and sums the digits of the fractional part. It works out how many digits need to be summed to reach or surpass 666 and keeps a tally of the ratio of those sums that attain 666 exactly, compared with the number of roots tried.

For the first 10,000 such roots, the fraction that sum to 666 is 0.1975 which is NOT 2/9 :(

The number of digits required tends to vary between about 130 and 170

Here is the output of the script: http://www.mround.pwp.blueyonder.co.uk/JREF/sumTo666.html

[ceptimus]

Oh. Here's the script if anyone wants to play around with it. It was only a quick and dirty hack, so please don't criticise the style :D You need to make sure that you have the bcmath module loaded if you want this to run under Apache.

<html>
<head>
<title>sum random digits to 666</title>
</head>
<body>
<?php
print "<TABLE BORDER=\"1\">\n<TR><TH>n</TH><TH>int(sqrt(n))</TH><TH>sqrt(n) - int(sqrt(n)) [first 20 digits]</TH><TH>1st digit sum >= 666</TH><TH>digits</TH><TH># = 666</TH><TH>#</TH><TH>ratio</TH></TR>\n";
$hits = $tries = 0;
for ($i = 2; $i <= 20000; $i++)
{
$root = bcsqrt($i, 210);
$integer = strtok($root, ".");
$fraction = strtok(".");
$fraction20 = substr($fraction, 0, 20);
if (intval($fraction) == 0)
continue;
for ($digit = 0, $sum = 0; $sum < 666; $sum += intval(substr($fraction, $digit++, 1)))
;
if ($sum == 666)
$hits++;

$tries++;

$ratio = $hits / $tries;
if ($tries <= 10 || ($tries < 1000 && ($tries % 100 == 0)) || ($tries % 1000 == 0))
print "<TR><TD>$i</TD><TD>$integer</TD><TD>$fraction20</TD><TD>$sum</TD><TD>$digit</TD><TD>$hits</TD><TD>$tries</TD><TD>$ratio</TD></TR>\n";

if ($tries > 10000)
break;
}
print("</TABLE>\n");
?>
</body>
</html>

[xorbie]

IOW, I've interpreted the problem as being given an infinite number of digits, each of which is randomly chosen. If we already know what each digit is, then we can already figure out if an n exists simply by adding up the digits as we go along.

Ah, but we start by fixing x (the irrational number in (0,1)), so the digits of x are determined at the beginning...they no longer vary for the rest of the problem.

To address your analogy, since we've fixed the (2004) World Series champs as the Red Sox, the probability of the Red Sox being the 2004 World Series champs is 1.

On the other hand, if you let both x and n vary....eeeep! That would be even worse!

But again, given a certain number x that is fixed, the probability is either 0 or 1. That's not a statistics problem, it's an arithmetic problem.

[Goliath]

But again, given a certain number x that is fixed, the probability is either 0 or 1. That's not a statistics problem, it's an arithmetic problem.

Correct, if we fix x first. However, if we let the decimal places of x vary, then the problem becomes much more complicated.

[Shake]

Warren may be a thread-killer, but I've managed to derail this one pretty damn well!

Yes, the intent of my first post in this thread was discovered. I did indeed mean the first 144 digits of pi!

OK, another one of my favorite Pi properties (or is it an e property?):
e^(i*Pi) + 1 = 0

e being this number (http://antwrp.gsfc.nasa.gov/htmltest/gifcity/e.1mil)