...you are saying that the answer is a number greater than 1...
Yep. 1.2968395546510096...
Replacing x with your answer gives the equation "infinity = 8", which is clearly wrong.
Where did you get that infinity from? Please show how you have proved that y ^ (y ^ (y ^ (y ^ (y ^ (...))))) = infinity. Where y = 1.2968395546510096....
Your logic is faulty.
Not according to Leonard Euler.
@Electrodude
Well, whatever we do we are going to run out of digits. Computers are limited. What we want is some logical proof of the result we can understand. The actual digits are not so important.
My program was faulty. In the loop, I had $y **= $x. It should have read $y = $x ** $y. When I do this instead, I get an answer closer to 1.44... Not sure why the difference.
What does it mean to have that infinite power tower anyway? At first sight this seems impossible. How can we do anything an infinite number of times anyway? Surely any positive number bigger than 1 will explode to an infinite value!
So the problem is:
y = x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (.......))))))))
Where '^' is the power operator an '...' means we are doing this an infinite number of time.
What is the value of x when y = 8 ?
But we can claim that everything in the outside braces is just a copy of the entire right hand side of our equation. So we can rewrite it as:
8 = x ^ (8)
From which we can calculate that x = 1.2968395546510096... as shown in previous posts.
At this point a big red light should flash in your mind. You can't do that. Messing with infinite series like that is very suspicious.
So I thought, how can we give meaning to the number 1.2968395546510096... here?
Well let's do our rewrite a bit differently. That whole power tower should equal 8, and the stuff in the "..." is just the same power tower so that is also 8. So we can write:
y = x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (8))))))))
That's better. It's a real thing we can calculate. Let's write a program for it:
function tower (x, y, depth) {
if (depth > 0) {
let y2 = Math.pow(x, tower(x, y, --depth));
return(y2);
} else {
return(8);
}
}
let y = tower(1.2968395546510096, 8, 20);
console.log(y);
That recursively performs the power operation 'depth' number of times. Starting with our magic number. It outputs 7.9999999964874355. Pretty close to 8.
That is not the infinite calculation the problem asks for but it seems to be working well so far.
Lets's play with this. We can run it for initial values either side of the magic number and see what we get. For example starting with 1.2968385546510097 gives us 1.2968385546510097. Far away from 8. We can run for higher levels of power raising (increase the "depth") thus getting closer to the problems infinite stack.
I plot the error, the deviation from 8, for some some values around our magic number and the graph below (Sorry the axis labels are a mess.)
We see that the error gets vanishingly small as we get close to some magic number. Hence we can see that it does make sense to assign a value to that crazy power stack.
My program was faulty. In the loop, I had $y **= $x. It should have read $y = $x ** $y. When I do this instead, I get an answer closer to 1.44... Not sure why the difference.
That 1.44...sounds eerily familiar...
I decided to work this power stack problem with e instead of 8. So:
e = x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (.....)))))))
And using the methods described previously we get a solution of:
x = e ^ (1 / e)
Which just happens to equal 1.444667861009766
Would that happen to be the the number you got Phil?
It seems we are in a very special place when we get to that solution. For values of x less than that we have a small(ish) error. For values above that the error rapidly shoots to infinity. But just at the magic value the error almost vanishes.
I calculated the power tower 45 iterations high for values a bit below and a bit above 1.444667861009766 and plotted the results.
I think it's fascinating, the error floats along horizontally nicely, dips to almost zero( e ^ -30) at just the right value, then shoots up to infinity almost immediately (floating point overflow).
Here is the code:
let e = Math.E;
let x = Math.pow (e, 1/e);
function tower (x, y, depth) {
if (depth > 0) {
let y2 = Math.pow(x, tower(x, y, --depth));
return(y2);
} else {
return(e);
}
}
let δx = 0.0002;
let startX = x - (10 * δx);
let endX = x + (10 * δx);
for (x = startX; x < endX; x += δx) {
let y = tower(x, e, 45);
let error = Math.abs(y - e);
console.log(x, Math.log(error, 10));
}
And using the methods described previously we get a solution of:
x = e ^ (1 / e)
Which just happens to equal 1.444667861009766
Would that happen to be the the number you got Phil?
I got 1.44466786101036 by my brute-force successive approximations method. The "tower" at that point was 4194304 "stories" high. I'm sure that round-off was a killer after that many powers.
I'm starting to think what you are trying to do is impossible. Here is why...
I thought: Why not just do the X ^ (X ^ (X ^ (X ^ (X ^ (X))))))) thing a finite number of times and see were we get when we do a stack a few thousand high on our assumed solutions.
This is where it gets weird....
I create a function that just loops around raising to the power, N number of times, and returns the result.
I call that function for my solution to e = X ^ (X ^ (X ^ (X ^ (X ^ (....))))))) and have it iterate a thousand times. The result is almost e but not so close. So I iterate a million times. That's better. What about a billion? That gets me e with a 5e-8 error..
The code:
// Verify that e ^ (e ^ (e ^ (e ^ (...)))) = e
// For a small value of infinity :)
// Raise x to the power x, to the power x, to the power x .... order times
function tetration (x, order) {
let y = Math.pow(x, x);
for (let i = 0; i < order; i += 1) {
y = Math.pow(x, y);
}
return y;
}
// A convenient definition of e.
let e = Math.E;
// Our assumed solution
let x = Math.pow(e, 1/e);
// Do the power tower our assumed soluton
let y = tetration(x, 1000000000);
console.log('x =', x);
console.log('y =', y);
console.log('Expected: y =', e);
console.log('Error = ', y - e);
Output:
x = 1.444667861009766
y = 2.718281772435808
Expected: y = 2.718281828459045
Error = -5.602323716047408e-8
But what about our original problem with 8, which has the contentious solution 8 ^ 1 / 8 ?
8 = X ^ (X ^ (X ^ (X ^ (X ^ (....)))))))
I tweak the code like so:
// Verify that x ^ (x ^ (x ^ (x ^ (...)))) = 8
// When x = 8 ^ (1/8)
// For a small value of infinity :)
// Raise x to the power x, to the power x, to the power x .... order times
function tetration (x, order) {
let y = Math.pow(x, x);
for (let i = 0; i < order; i += 1) {
y = Math.pow(x, y);
}
return y;
}
// Our assumed solution
let x = Math.pow(8, 1/8);
// Do the power tower our assumed solution
let y = tetration(x, 1000000000);
console.log('x =', x);
console.log('y =', y);
console.log('Expected: y =', 8);
console.log('Error = ', y - 8);
Output:
x = 1.2968395546510096
y = 1.4625014315037788
Expected: y = 8
Error = -6.537498568496221
Miserable. Not even close with a power stack one billion high!
Of course doing a billion iterations above is a waste of time. In the case of the tetration for e the thing gets nearly to e after raising to the power a hundred times or so, then gets stuck. As this graph shows:
The tetration to 8 is even worse:
Basically, the thing converges really slowly and runs out of bits at some point so it can't make any more progress.
Ok, this is what I Think is happening, especially in the most recent graphs posted. When x=e^(1/e) which is maximum, then x to infinite powers of itself equals e. That's the highest it can go without blowing up. Let's try to go higher to get 4.
4^(1/4)= the square root of 2= x. You get the same result for 2^(1/2). The square root of 2 to infinite powers of itself can't equal both, it equals 2, which is less than e. The graph that tries to reach 8 likewise seems to be converging on another solution whose value is less than e. So I assume that something magic about e unexpectedly allows some finite results greater than 1, but not greater than e.
This is a interesst issue, thx.
attached a diagram with f(x) = x ** x, x ** x ** x , x ** x ** x ** x ... and so on.
The vertical red and blue lines are the euler Limits.
the black function x ** 8 has an intersection with the horizontal line x=8 near by the function x**x**x**x**x**x**x**x**x.
The corresponding x-value is 1.2968....
the thing is, euler found this all without a Computer ;-)
I was about to make the same point as Phil. The bracketing is different.
It's not yet clear to me what x ** 8 has to do with this.
But he does seem to have the same 1.2968... result.
As far as I can tell x = 1.2968... is within the limits that Euler found for convergence of the infinite tetration of x. Therefore our result of 8 is valid.
phipi>> think your operator grouping is wrong. It's not ((((x**x)**x)**x)**x, but x**(x**(x**(x**(x**x)))).
I say neither the one nor the other
I construct the functions in the diagram by this way:
f(x) = x ** x
g(x) = f(x) ** x
h(x) = g(x) ** x
... and so on
the formula with the brackets is created by my tool (geogebra) after Input each function.
the best way to Input with brackets is x**(x*x*x*x*x*x*x*x) , this give the identical graph as f1(x) in the diagram above.
heater>> Therefore our result of 8 is valid.
yes ;-)
heater>> It's not yet clear to me what x ** 8 has to do with this.
this is coming from yourself
>> What is X ?
>> Noticing that everything after the ^ on the left hand side is the same as the left hand side itself, when carried to infinity, we can rewrite that as:
PhiPi,
you are right, I have not well understand the problem.
After I read the german translation from the Wiki
I have correctly recognized the connections.
According to wikipedia and others the infinite tetration of x that is to say x ^ (x ^ (x ^ (...)) can be evaluated with the Lambert Function, W.
W(-ln(x)) / -ln(x)
That is assuming it converges at all, which the Euler condition mentioned above suggests it should.
What is this Lambert Function? Well see the nice and short mathona videos here:
and here:
Now, that means we need to calculate the natural log of our proposed solution 1.2968395546510096 which is 0.25993019270997947 and then take the W function of minus that.
So soon we have not just one but two possible answers: -2.079442 and -0.380148
Hmm..Let's take the first one. Then we have:
W(-ln(x)) / -ln(x) = -2.079442 / -ln(x)
= 2.079442 / 0.2599301927099
= 8.00000176324572
Close enough. Hey I was right after all.
Phew!
Of course all of that is just a long way of calculating the eighth root of eight as we did originally. The whole Lambert W thing does not add much. But I bet W gets more interesting when working with complex numbers.
>> What an interesting road this is...
yes, and some CAS Tools ,like MuPad et.al , have the Lambert W built in.
Meanwhile I can figure out the exp_Tower correct.
the blue graph is the Tower with 10 floors.
Now I found the Inversfunction to that, f(x) = exp(ln(x) / x) , the green plot.
Furthermore, I find it interesting that the derivation of the function (orange) exactly between the euler limits greater than zero is.
Probably the slope is outside too low to convert quickly.
Comments
@Electrodude
Well, whatever we do we are going to run out of digits. Computers are limited. What we want is some logical proof of the result we can understand. The actual digits are not so important.
-Phil
In this case Euler says it's OK. I might never understand why.
So the problem is:
y = x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (.......))))))))
Where '^' is the power operator an '...' means we are doing this an infinite number of time.
What is the value of x when y = 8 ?
But we can claim that everything in the outside braces is just a copy of the entire right hand side of our equation. So we can rewrite it as:
8 = x ^ (8)
From which we can calculate that x = 1.2968395546510096... as shown in previous posts.
At this point a big red light should flash in your mind. You can't do that. Messing with infinite series like that is very suspicious.
So I thought, how can we give meaning to the number 1.2968395546510096... here?
Well let's do our rewrite a bit differently. That whole power tower should equal 8, and the stuff in the "..." is just the same power tower so that is also 8. So we can write:
y = x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (8))))))))
That's better. It's a real thing we can calculate. Let's write a program for it:
function tower (x, y, depth) { if (depth > 0) { let y2 = Math.pow(x, tower(x, y, --depth)); return(y2); } else { return(8); } } let y = tower(1.2968395546510096, 8, 20); console.log(y);That recursively performs the power operation 'depth' number of times. Starting with our magic number. It outputs 7.9999999964874355. Pretty close to 8.That is not the infinite calculation the problem asks for but it seems to be working well so far.
Lets's play with this. We can run it for initial values either side of the magic number and see what we get. For example starting with 1.2968385546510097 gives us 1.2968385546510097. Far away from 8. We can run for higher levels of power raising (increase the "depth") thus getting closer to the problems infinite stack.
I plot the error, the deviation from 8, for some some values around our magic number and the graph below (Sorry the axis labels are a mess.)
We see that the error gets vanishingly small as we get close to some magic number. Hence we can see that it does make sense to assign a value to that crazy power stack.
I decided to work this power stack problem with e instead of 8. So:
e = x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (x ^ (.....)))))))
And using the methods described previously we get a solution of:
x = e ^ (1 / e)
Which just happens to equal 1.444667861009766
Would that happen to be the the number you got Phil?
It seems we are in a very special place when we get to that solution. For values of x less than that we have a small(ish) error. For values above that the error rapidly shoots to infinity. But just at the magic value the error almost vanishes.
I calculated the power tower 45 iterations high for values a bit below and a bit above 1.444667861009766 and plotted the results.
I think it's fascinating, the error floats along horizontally nicely, dips to almost zero( e ^ -30) at just the right value, then shoots up to infinity almost immediately (floating point overflow).
Here is the code:
let e = Math.E; let x = Math.pow (e, 1/e); function tower (x, y, depth) { if (depth > 0) { let y2 = Math.pow(x, tower(x, y, --depth)); return(y2); } else { return(e); } } let δx = 0.0002; let startX = x - (10 * δx); let endX = x + (10 * δx); for (x = startX; x < endX; x += δx) { let y = tower(x, e, 45); let error = Math.abs(y - e); console.log(x, Math.log(error, 10)); }I got 1.44466786101036 by my brute-force successive approximations method. The "tower" at that point was 4194304 "stories" high. I'm sure that round-off was a killer after that many powers.
-Phil
Yeah. I always worry about accumulated errors when we deal with such iterative procedures.
But wow, a tower 4194304 high is crazy!
It must be possible to use successive approximation to get a good result with a tower of 20. Or 45, like my graph above shows.
I'm starting to think what you are trying to do is impossible. Here is why...
I thought: Why not just do the X ^ (X ^ (X ^ (X ^ (X ^ (X))))))) thing a finite number of times and see were we get when we do a stack a few thousand high on our assumed solutions.
This is where it gets weird....
I create a function that just loops around raising to the power, N number of times, and returns the result.
I call that function for my solution to e = X ^ (X ^ (X ^ (X ^ (X ^ (....))))))) and have it iterate a thousand times. The result is almost e but not so close. So I iterate a million times. That's better. What about a billion? That gets me e with a 5e-8 error..
The code:
// Verify that e ^ (e ^ (e ^ (e ^ (...)))) = e // For a small value of infinity :) // Raise x to the power x, to the power x, to the power x .... order times function tetration (x, order) { let y = Math.pow(x, x); for (let i = 0; i < order; i += 1) { y = Math.pow(x, y); } return y; } // A convenient definition of e. let e = Math.E; // Our assumed solution let x = Math.pow(e, 1/e); // Do the power tower our assumed soluton let y = tetration(x, 1000000000); console.log('x =', x); console.log('y =', y); console.log('Expected: y =', e); console.log('Error = ', y - e);Output: But what about our original problem with 8, which has the contentious solution 8 ^ 1 / 8 ?8 = X ^ (X ^ (X ^ (X ^ (X ^ (....)))))))
I tweak the code like so:
// Verify that x ^ (x ^ (x ^ (x ^ (...)))) = 8 // When x = 8 ^ (1/8) // For a small value of infinity :) // Raise x to the power x, to the power x, to the power x .... order times function tetration (x, order) { let y = Math.pow(x, x); for (let i = 0; i < order; i += 1) { y = Math.pow(x, y); } return y; } // Our assumed solution let x = Math.pow(8, 1/8); // Do the power tower our assumed solution let y = tetration(x, 1000000000); console.log('x =', x); console.log('y =', y); console.log('Expected: y =', 8); console.log('Error = ', y - 8);Output: Miserable. Not even close with a power stack one billion high!P.S. "tetration" is whole new word to me!
The tetration to 8 is even worse:
Basically, the thing converges really slowly and runs out of bits at some point so it can't make any more progress.
See my working here:
http://forums.parallax.com/discussion/comment/1387510/#Comment_1387510
and Electrodude's simpler working here:
http://forums.parallax.com/discussion/comment/1387546/#Comment_1387546
But you are right. Whilst the power tower converges on a result for 1.296839554 it does not do so for any old value.
See wikipedia: https://en.wikipedia.org/wiki/Tetration#Extension_to_infinite_heights
The maximum input for convergence is e^(1/e) or about 1.44.
Given we start with X = 1.296839554... which is less than 1.44 I think we are good.
4^(1/4)= the square root of 2= x. You get the same result for 2^(1/2). The square root of 2 to infinite powers of itself can't equal both, it equals 2, which is less than e. The graph that tries to reach 8 likewise seems to be converging on another solution whose value is less than e. So I assume that something magic about e unexpectedly allows some finite results greater than 1, but not greater than e.
attached a diagram with f(x) = x ** x, x ** x ** x , x ** x ** x ** x ... and so on.
The vertical red and blue lines are the euler Limits.
the black function x ** 8 has an intersection with the horizontal line x=8 near by the function x**x**x**x**x**x**x**x**x.
The corresponding x-value is 1.2968....
the thing is, euler found this all without a Computer ;-)
sorry I mean intersection with the horizontal line y=8
I think your operator grouping is wrong. It's not ((((x**x)**x)**x)**x, but x**(x**(x**(x**(x**x)))).
I made the same mistake initially.
-Phil
It's not yet clear to me what x ** 8 has to do with this.
But he does seem to have the same 1.2968... result.
As far as I can tell x = 1.2968... is within the limits that Euler found for convergence of the infinite tetration of x. Therefore our result of 8 is valid.
1.4625^(1/1.4625)=1.2968 too.
Where did 1.4625 come from? Tetration of 1.2968.
Can it be valid for 8 when it actually does 1.4625?
I say neither the one nor the other
I construct the functions in the diagram by this way:
f(x) = x ** x
g(x) = f(x) ** x
h(x) = g(x) ** x
... and so on
the formula with the brackets is created by my tool (geogebra) after Input each function.
the best way to Input with brackets is x**(x*x*x*x*x*x*x*x) , this give the identical graph as f1(x) in the diagram above.
heater>> Therefore our result of 8 is valid.
yes ;-)
heater>> It's not yet clear to me what x ** 8 has to do with this.
this is coming from yourself
>> What is X ?
>> Noticing that everything after the ^ on the left hand side is the same as the left hand side itself, when carried to infinity, we can rewrite that as:
>> X ^ 8 = 8
http://forums.parallax.com/discussion/164866/the-collatz-conjecture-is-a-simple-problem-that-mathematicians-can-t-solve#latest
Maybe your not talking about the same number.
But that's the wrong order of operations, per the original problem statement. It should be:
f(x) = x ** x
g(x) = x ** f(x)
h(x) = x ** g(x), etc.
-Phil
you are right, I have not well understand the problem.
After I read the german translation from the Wiki
I have correctly recognized the connections.
mia culpa
According to wikipedia and others the infinite tetration of x that is to say x ^ (x ^ (x ^ (...)) can be evaluated with the Lambert Function, W.
W(-ln(x)) / -ln(x)
That is assuming it converges at all, which the Euler condition mentioned above suggests it should.
What is this Lambert Function? Well see the nice and short mathona videos here:
and here:
Now, that means we need to calculate the natural log of our proposed solution 1.2968395546510096 which is 0.25993019270997947 and then take the W function of minus that.
Hmm...How to calculate W(-0.210574) ?
Luckily there is a Lambert Function calculator on line here: http://www.had2know.com/academics/lambert-w-function-calculator.html
So soon we have not just one but two possible answers: -2.079442 and -0.380148
Hmm..Let's take the first one. Then we have:
W(-ln(x)) / -ln(x) = -2.079442 / -ln(x)
= 2.079442 / 0.2599301927099
= 8.00000176324572
Close enough. Hey I was right after all.
Phew!
Of course all of that is just a long way of calculating the eighth root of eight as we did originally. The whole Lambert W thing does not add much. But I bet W gets more interesting when working with complex numbers.
What an interesting road this is...
yes, and some CAS Tools ,like MuPad et.al , have the Lambert W built in.
Meanwhile I can figure out the exp_Tower correct.
the blue graph is the Tower with 10 floors.
Now I found the Inversfunction to that, f(x) = exp(ln(x) / x) , the green plot.
Furthermore, I find it interesting that the derivation of the function (orange) exactly between the euler limits greater than zero is.
Probably the slope is outside too low to convert quickly.
am still excited ;-)
heater found the solution x = 8 **(1/8) = 1.296839......
yesterday I found the solution x = exp(ln(8)/8) = 1.296839......
so the proof
8 **(1/8) = exp(ln(8)/8) // log both sides
1/8 * ln(8) = ln(8)/8 * ln(e) = ln(8)/8 = 1/8 * ln(8)
This is all cooked only with water ;-)