Ooh, brilliant work yet again! Very tickled to see a natural w^2 construction.
@CaptainMarcia: I would really advise against having multiple bases in your estimates, the average reader is really not going to be able to figure out which is bigger between Knuth expressions with different numbers in the expressions other than at the very end. So they're not going to know that 2^^^ and 3^^^ are pretty much indistinguishable other than at low numbers, so that 2^^^^ and 3^^^^ will differ by at most a small offset. Everyone seems to like using 2 as the base whenever possible, and to use 3 if 2 doesn't work... because the smallest numbers are the best when pursuing large numbers? I don't really agree though, and the thing that I was worried about did appear in discussions of Varhey's 3 card challenge, when the record was about 2^^2^^7; a lot of commenters had a hard time understanding how much that was (understandably), and were unsure how it compared to even numbers like googol or googolplex. I'm not saying they would have necessarily figured that out if it were 10^^10^^4 or 10^^10^^5 (not sure if the latter still works as an upper bound for that particular deck), but it's definitely easier to see with 10 instead of 2, and maybe at least one person in the thread would have figured that those numbers are bigger than a googolplex and could have explained it to the rest.
Of course, replacing "use the smallest number possible as the base" with "use the biggest number possible as the base" doesn't work since you can go very very high, and also using numbers like googolplex or Graham's number as the base might seem a bit gratuitous... so I'm fine with using 10 as the default base, that's the base for scientific notation anyway.
So that's my spiel for using 10 as the base, but really the most important thing is to use a consistent base for all the estimates.
Converting bases is an option, but I'm hesitant to use conversions that would reduce the reported score in situations where it doesn't make it shorter to write. The writeup does make a point of contextualizing the numbers in terms of more familiar ones like googolplex, and I can add examples of how they might translate to other bases, but for this specific deck, the topic of how its score translates to base 3 is particularly relevant due to that being the base used for Graham's Number.
Which doesn't necessarily rule out using a consistent base for the final scoring, but I'm not sure how significant it would be.
While it's true that (3^^^^(3^^^(3^^3^^3^^18))) is larger than (2^^^^(2^^^(2^^2^^3^^18))), the notion that the change between the early 3's and 2's has any significance is far more misleading than just thinking of them as identical. For example, (3^^^^(3^^^(3^^3^^3^^18))) is less than (2^^^^(2^^^(2^^2^^([3^^18)+2])), and is much closer to (2^^^^(2^^^(2^^2^^3^^18))) than tp (2^^^^(2^^^(2^^2^^([3^^18)+2])). So making those early bases higher in this situation, feels fraudulent; if you want a better lower bound, start with the most significant part of the expression, which in case is the power tower 3^^18. While expanding 3^^18 into an exponential tower is kind of a pain, that's the only way you'll get a legitimately good estimate, in the sense that the best lower bound is somewhere between 3^^18 = 3^3^3^...^3, and 3^^19 = 3^3^3^...^27, so there is some number 3^3^3^...^x where the choice of x gives the highest integral value of the power tower that still makes the full expression a lower bound. So figuring out that x is between, say, 16.454 and 16.455, gives you a significantly better estimate. On the other hand, increasing the earlier bases from 2 to 3, or even from 2 to googolplex, will be the same as increasing 3^3^3^...^3 to 3^3^3^...^(3.0000000....), where if we wanted to get to something other than 0 in the 3.00000... we would need more digits than could be stored in with the computational capacity of the observable universe. So REALLY doesn't get you anywhere from 3 to the best value... but if you use your expression with increased bases, people will not know that this is the case, rather they will expect that it makes some kind of difference if you deliberately put in larger bases.
Anyway that's my position. The biggest point for me is that readers will be confused by all the different bases, and how that will affect the size of the estimates. The most important thing to understand is that generally the value of the bases don't make a difference, but probably the best way to handle that is to simply use the same bases.
Edit: Oh and I also argued against having 2 be the preferred base in the previous post. I think 10 is fine, and of course the estimate will be *larger* with 10's than with 3's, if you consider that important.
While it's true that (3^^^^(3^^^(3^^3^^3^^18))) is larger than (2^^^^(2^^^(2^^2^^3^^18))), the notion that the change between the early 3's and 2's has any significance is far more misleading than just thinking of them as identical. For example, (3^^^^(3^^^(3^^3^^3^^18))) is less than (2^^^^(2^^^(2^^2^^([3^^18)+2])), and is much closer to (2^^^^(2^^^(2^^2^^3^^18))) than tp (2^^^^(2^^^(2^^2^^([3^^18)+2])). So making those early bases higher in this situation, feels fraudulent; if you want a better lower bound, start with the most significant part of the expression, which in case is the power tower 3^^18. While expanding 3^^18 into an exponential tower is kind of a pain, that's the only way you'll get a legitimately good estimate, in the sense that the best lower bound is somewhere between 3^^18 = 3^3^3^...^3, and 3^^19 = 3^3^3^...^27, so there is some number 3^3^3^...^x where the choice of x gives the highest integral value of the power tower that still makes the full expression a lower bound. So figuring out that x is between, say, 16.454 and 16.455, gives you a significantly better estimate. On the other hand, increasing the earlier bases from 2 to 3, or even from 2 to googolplex, will be the same as increasing 3^3^3^...^3 to 3^3^3^...^(3.0000000....), where if we wanted to get to something other than 0 in the 3.00000... we would need more digits than could be stored in with the computational capacity of the observable universe. So REALLY doesn't get you anywhere from 3 to the best value... but if you use your expression with increased bases, people will not know that this is the case, rather they will expect that it makes some kind of difference if you deliberately put in larger bases.
Anyway that's my position. The biggest point for me is that readers will be confused by all the different bases, and how that will affect the size of the estimates. The most important thing to understand is that generally the value of the bases don't make a difference, but probably the best way to handle that is to simply use the same bases.
Edit: Oh and I also argued against having 2 be the preferred base in the previous post. I think 10 is fine, and of course the estimate will be *larger* with 10's than with 3's, if you consider that important.
Okay, yeah, from that perspective I can see it. I've edited to base 2, with an explanation of the logic behind it as well as the applicability of base 10 as well.
I've continued the 12-card writeup to the hyperstage section, but looking back over what I've written - we fuel the hyperstage with -1/1 Exalted Sunborn tokens, but playing Saw in Half on a -1/1 makes more -1/1s. Doesn't that go infinite?
Private Mod Note
():
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Which doesn't necessarily rule out using a consistent base for the final scoring, but I'm not sure how significant it would be.
Anyway that's my position. The biggest point for me is that readers will be confused by all the different bases, and how that will affect the size of the estimates. The most important thing to understand is that generally the value of the bases don't make a difference, but probably the best way to handle that is to simply use the same bases.
Edit: Oh and I also argued against having 2 be the preferred base in the previous post. I think 10 is fine, and of course the estimate will be *larger* with 10's than with 3's, if you consider that important.
I spotted several errors in the writeup:
Thanks, fixed.