fun with number 8
msrobots
Posts: 3,709
Just stumbled about this:
Enjoy!
Mike
1 * 8 + 1 = 9 12 * 8 + 2 = 98 123 * 8 + 3 = 987 1234 * 8 + 4 = 9876 ....
Enjoy!
Mike
Comments
Your messed up code tags are driving me crazy though
12345 * 8 + 5 = 98765
123456 * 8 + 6 = 987654
1234567 * 8 + 7 = 9876543
12345678 * 8 + 8 = 98765432
123456789 * 8 + 9 = 987654321
12345678910 * 8 + 10 = 98765431290
Durp, what am I supposed to now?
Enjoy!
Mike
I'm still trying to figure out the value of X if:
X to the power(X to the power(X to the power(X to the power(X to the power(X to the power(X to the power(X to the power(X to the power(...))))))))) = 8
Any ideas?
Yes, X == 1.5168551732304
Edit: Actually, I'm not believing that answer. I think my Perl program might've overflowed somewhere without my knowing it. My calculator puts the lie to such a high number.
Edit 2: Took care of the overflow. The correct answer is X == 1.29683955465101
-Phil
Just use a larger base! It won't be 8 anymore, though: it seems to me that it will always be baseN:10 - 2, i.e. the second highest digit in that base.
For example, base36:123456789abcdefghijklmnopqrstuvwxyz * base36:y + base36:z = base36:zyxwvutsrqponmlkjihgfedcba987654321
Everyone should install spigot. It's an infinite precision calculator that can do any base up to 36 and prints out digits forever as it comes up with them. It's great for all sorts of useless things, ranging from doing math in unusual bases to quickly evaluating lots of digits of sin(1e-1000) (which has interesting repeating digit patterns). You can even use Unix pipes to pipe numbers through it. There is a Windows version, but the author says it's slower. It's written by the same guy who wrote PuTTY.
Mine goes like this:
I went out and got drunk, when I woke up in the morning strangely I had the same number on my screen as you.
We have X ^ ( X ^ (X ^ (X ^ (...)))) = 8
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
Take the log to the base 2 of both sides:
log(X ^ 8 ) = log(8)
Rearrange a bit:
8 * log( X ) = 3
log( X ) = 3 / 8
Un log it:
X = 2 ^ (3 / 8 )
Pull out the calculator, well Javascript terminal:
X = Math.pow(2, 3/8) = 1.2968395546510096
Not quite the same as your result but pretty close. I guess perl can't do maths properly
We need to test it. Let's write a program: Hmmm...that's no good. The stack will blow up. We need a bottom case to limit the recursion. Like so: But what to return when we bottom out? Why 8 of course, that is what we are told the result should be after all. OK. Let's run that for a few numbers and a recursion depth of 10...
Firstly with my result: Not bad, nearly 8.
What about Phil's result: Pretty good.
What about some nearby numbers: Looks like our results are good, they get us closer to 8 than any of those.
What if we recurse more: We get: Ooops. The harder we work the worse it gets. Then it blows up!
Here's its output:
-Phil
Seems to be a bit of a lucky fluke that it works though. I can do that in Javascript:
Which for some odd reason produces a different and closer result: But how do we know this is correct? How do we know that the loop doing the power raising does not blow up? For example if I iterate 7 or 9 times instead of 8 I get very different results:
7 times gives
1.3287967293444227 8.00000000000001
9 times gives
1.2711734332303317 8.000000000000046
!!!
I think that enough nerding out for the day. Might have to do some real work
If you change the loop limit, you're computing a different function. The reason for the loop -- and testing inside it -- is to keep the function from blowing up, i.e. if I know x**x**x is too big, then x**x**x**x ...**x surely is, so I don't have to keep iterating. Truth be known, I should have written last if $y > 9 or somesuch, instead of 8, to make sure the result was going to be way too big.
-Phil
Could you explain.
What we want is to that power raising forever.Which we cannot. So we have to break out at some point. Like:
1) The result is growing too big to be correct.
2) The loop hangs, like it does if we start with 1.
But, we get different results depending on the limit we use in 1).
So, how do we know an 8 iteration limit is the correct function? Why not 9?
When I fiddle with that iteration limit I get very different results.
Perhaps we can change the loop limit incrementally to see if the results approach some asymptotic limit.
-Phil
The output:
-Phil
1 to ANY power is still 1!
It's those dots that make the whole problem really weird.
On the other hand it allows us to create that solution I came up with using log base 2.
But that solution does not feel right because repeatedly raising 1.2...whatever to a power bigger than 1 feels like it should always run to infinity!
-Phil
1 to the 1 to the 1 to the 1 to the ... = 8
is
1 to the (1 to the 1 to the 1 to the ...) = 8
Where the part in braces is the same as what we started with, which we are told is 8. So we can write:
1 to the 8 = 8
But that is wrong. 1 to the 8 = 1.
My solution using logs above seems more plausible.
Does the question make sense. Sure in the same way that
1 + 2 + 3 + 4 + 5 + ... = -1/12
does.
It makes as much sense as root (1 + root (1 + root (1 + root (1 + root (1 + root (1 + ...)))))) = φ
Which I think you will like:
x^(x^(x^(x^(...)))) = 8
The stuff inside the outermost set of parentheses is the same as the whole LHS, which equals 8. Therefore,
x^8 = 8
x = 8^(1/8)
And...
It doesn't matter how infinitessimally close to 1 X is without reaching it. The infinite progression of powers will blow up to infinity. It will never equal 8. Therefore there is no solution, even though it asymptotically approaches 1.
-Phil
Heater's faulty logic was in the statement "Noticing that everything after the ^ on the left hand side is the same as the left hand side itself, when carried to infinity". This is only true if x equals 1. However, it x is one, then the result is also 1, and not 8. Hence, there is no solution.
I can't go with the exploding argument.
In order to calculate:
1 to the 1 to the 1 to the 1 to the ...
We start with a 1 and then have to raise it to the power (1 to the 1 to the 1 to the 1 to the ...)
Which is he same as our original problem. We can not even start. How can we say it explodes? Or how can we say it asymptotically approaches anything in particular?
@Dave Hein, That does not sound right. It's not a valid question. That thing is not an equation.
What you have is two functions:
f(x) = 11+3x-7 = 3x + 4
and
f'(x) = 6x+5-3x = 3x + 5
So the questions might be:
Is there a value of x for which f(x) = f'(x) ?
Might be, might not be. Might be a complex solution.
Or, are those two functions actually the same thing? Are they an identity?
How is everything after the ^ not the same as what I started with? The thing I start with is a "power tower" running to infinity. I have
to raise that first X to the power of the same power tower running to infinity.
@Electrodude
Wow, thankyou. I think I love spigot. It agrees with me Odd I have never heard of it, must check it out.
Now, I agree with everyone, there is a very suspect assumption in my "proof". Perhpas the Mathologer has a better answer. He did not say in the video
that he posed the problem in.
Before anyone rights this kind of thing off as meaningless, don't forget that when Newton invented the differential calculus his main trick
is in finding a way to calculate 0/0 and get a meaningful result!
While bored in 7th grade math class, I discovered that 1+1/(1+1/(1+1/(1+1/(1+1/(1+1/(...)))))) = φ. Eventually, I found out about continued fractions, and learned that φ as a continued fraction is [1;1,1,1,1,1,1,1,1,...], which is basically what I came up with. I don't know why infinite continued fractions work but Ramanujan's formula for 3 doesn't.
Double floats are nowhere near enough for the sort of math we're doing here. I took the value for x that Heater came up with (1.29683955..., I needn't post the rest again), and had calc (C style arbitrary precision calculator) run the following script on it to evaluate x^x^x^x^x^x...: It gave 8 plus some, with the last third or so of the digits being non-zero. If I change epsilon to 1e-10000, the error goes away. If I let it go long enough, it would blow up.
This only goes to show that there is yet another way to mislead with an inductive "proof."
-Phil
From wikipedia: https://en.wikipedia.org/wiki/Tetration#Extension_to_infinite_heights
'In general, the infinitely iterated exponential {\displaystyle x^{x^{\cdot ^{\cdot ^{\cdot }}}}} x^{x^{\cdot ^{\cdot ^{\cdot }}}}, defined as the limit of {\displaystyle {}^{n}x} {}^{n}x as n goes to infinity, converges for e−e ≤ x ≤ e1/e, roughly the interval from 0.066 to 1.44, a result shown by Leonhard Euler.[10] The limit, should it exist, is a positive real solution of the equation y = x^y. Thus, x = y^(1/y). '
Taking the part in bold there and applying it to the problem we have:
8 ^ (1 / 8 )
Or in Javascript:
Math.pow(8, 1 / 8 )
1.2968395546510096
Which is what I said it should be. And is Electrodude's solution.
Given that 1.2968395546510096 is less than e ^ (1 / e) then Euler says we are good to go.
Of course the tricky part here is proving our logic is correct. Euler could do it. I cannot