e^x = 10^(x / 2.302…), so, in particular, if we already have e^(e^(e^(e^e))) = 10^(10^(10^6.219…)), it follows that e^(e^(e^(e^(e^e)))) = 10^(10^(10^(10^6.219…)) / 2.302…). Division by 2.302… in the first exponent from the bottom of the tower is equivalent to subtracting 0.36… from the second exponent, which is equivalent to a microscopic change in the third exponent.

]]>http://www.wolframalpha.com/input/?i=e^%28e^%28e^%28e^%28e^%28e^%28e^%28e^%28e^e%29%29%29%29%29%29%29

]]>Any number has a power of 10 representation (and a power of e representation). See Wikipedia, “level-index arithmetic”. The counter-intuitive thing is “that putting a few more e’s down the bottom should result in it thinking there were the same number of extra 10s at the bottom.” However, try taking base-10 logarithms of a tall tower of e’s, and you’ll see why the resulting factors of 1/(ln 10) are vanishingly insignificant (until close to the end of the process).

(By the way, I can’t say I’m smart enough to figure this out on my own. I heard about it from Nick Trefethen, who made the same discovery as you and was equally startled by it.)

]]>My guess is that in computing e^(e^(e^(e^e))), the calculator begins by finding the value for e^(e^(e^e)). It then tries to compute e^2.33… × e^(10^(10^6.219196780089781)). The computation of the latter term fails along the way. For some reason(?), it does not die, but actually returns a value of 10^(expt) rather than e^(expt). This gives 10^(10^(10^6.219196780089781)).

Presumably the computation of e^(e^(e^(e^(e^e)))) fails in the same way, returning 10 to the power of (the incorrect result for) e^(e^(e^(e^e))). This would explain why another power of 10 gets tacked on for each additional e.

I’ve got no idea what kind of bug might be causing the 10^(expt) error, though. I’d be curious to find out!

]]>