## My number is bigger!

For all your silly time-killing forum games.

Moderators: jestingrabbit, Moderators General, Prelates

Fejfo
Posts: 5
Joined: Fri Mar 31, 2017 6:51 pm UTC

### Re:

warriorness wrote:Define a function Q such that Q(x) is x→x→...x, where the number of arrows in that sequence is equal to x→x→...x, where there are x arrows in that second chain.

Now define W(x) = Q(Q(...Q(x)...)) so there are Q(x) number of "Q"s in there.

My number is:

W((g_64)!)

(edit: threw a factorial in there for good measure)

To make it easier to compare:

Q(x) = x→x→...x, where the number of arrows in that sequence is equal to x→x→...x, where there are x arrows in that second chain.

x→x→...x, where there are x arrows in that second chain so x→(2)x arrows in the first chain
so

Q(x) = x→(2) (x→(2)x) < x→(2) 3 →(2) 2

W(x) = Q^Q(x) (x)
~= x→(2) Q(x) →(2) 2
< x →(2) 3 →(2) 3

So I'm pretty sure your number is smaller than
3→(3)→4

< f_1(3) = 3→(4)→3 (the function defined in my last comment)

Daggoth
Posts: 52
Joined: Wed Aug 05, 2009 2:37 am UTC

### Re: My number is bigger!

Beaten on page 3, halfway through. Here

Freddino18
Posts: 31
Joined: Thu Oct 27, 2016 9:40 pm UTC
Location: Disappeared after investigating titles

### Re: My number is bigger!

Every time I try, I get beaten down, either by someone pointing out that it's too small, or by someone pointing out that it is incalculably large.

Bow chicka bow wow.

Blenders!
GENERATION 23: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Shriekin' Criminal: Wu Tang, Voodoo Foote: pirate, Amos Quirell: wizard, Sun-Ray Fool: blues, Thomaz Hettkamp: Nazi, farty monkey snatcher, phire AvAtAr: 1337 h4x0r

Daggoth
Posts: 52
Joined: Wed Aug 05, 2009 2:37 am UTC

### Re: My number is bigger!

More like you haven't produced a number that wins while following the rules, it's understandable, the numbers on this thread are big

Freddino18
Posts: 31
Joined: Thu Oct 27, 2016 9:40 pm UTC
Location: Disappeared after investigating titles

### Re: My number is bigger!

The number of possible dick jokes.

Blenders!
GENERATION 23: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Shriekin' Criminal: Wu Tang, Voodoo Foote: pirate, Amos Quirell: wizard, Sun-Ray Fool: blues, Thomaz Hettkamp: Nazi, farty monkey snatcher, phire AvAtAr: 1337 h4x0r

Daggoth
Posts: 52
Joined: Wed Aug 05, 2009 2:37 am UTC

### Re: My number is bigger!

Freddino18
Posts: 31
Joined: Thu Oct 27, 2016 9:40 pm UTC
Location: Disappeared after investigating titles

### Re: My number is bigger!

Blenders!
GENERATION 23: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Shriekin' Criminal: Wu Tang, Voodoo Foote: pirate, Amos Quirell: wizard, Sun-Ray Fool: blues, Thomaz Hettkamp: Nazi, farty monkey snatcher, phire AvAtAr: 1337 h4x0r

Yet-One-More-Idiot
Posts: 9
Joined: Sat Jun 29, 2013 7:18 pm UTC

### Re: My number is bigger!

So, just wondering - what's the currently leading Biggest Number?

I just checked this thread and there's 40 pages of posts, I'm not archive-binging all of that at 3am on a Sunday. xD

Thegeniusyoshi
Posts: 0
Joined: Tue Jun 27, 2017 2:29 pm UTC

### Re: My number is bigger!

Imagine a function B, for which B(x) is 1 followed by x 0s.
Now imagine a function C for which C(x, y) is x factorialed y times. For example, C(10, 3) would ((10!)!)!.
My number is C(B(TREE(gA(g[sub]65,g65)[/sub]), B(TREE(gA(g[sub]65,g65)[/sub]))

Yakk
Poster with most posts but no title.
Posts: 11128
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

### Re: My number is bigger!

Thegeniusyoshi wrote:Imagine a function B, for which B(x) is 1 followed by x 0s.
Now imagine a function C for which C(x, y) is x factorialed y times. For example, C(10, 3) would ((10!)!)!.
My number is C(B(TREE(gA(g[sub]65,g65)[/sub]), B(TREE(gA(g[sub]65,g65)[/sub]))

Yakk wrote:I try to use the small/medium/large system to categorize numbers. Small is anything that doesn't use a particularly strong system. Medium uses something as powerful as the fast growing heirarchy and feeds it a reasonable cardinal. Large are some of the computability ones, or proof based ones, or large cardinal fast growing heirarchy ones.

B and C and A and g are "small" functions. They don't grow fast enough to really matter in this thread.

Tree appears to be a medium function.

So your value is "medium". And basically all of its size is because you used the word "TREE" and fed it a value bigger than 2.
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

Daggoth
Posts: 52
Joined: Wed Aug 05, 2009 2:37 am UTC

### Re: My number is bigger!

I'll give it a tighter bound for gigs and shittles

// is for commentary
restrict x to positive integers

B(x) = 10^x

x! < x^x // for x=>2
since x! = x*y1*y2... where all yn are smaller than x and the amount of multiplicands is equal to x
and x^x = x*y1*y2... where all yn are not smaller than x and the amount of multiplicands is equal to x

x!! = (x!)! < (x^x)^(x^x) = x^(x*(x^x)) = x^((x^1)*(x^x)) = x^x^(x+1) which is roughly x^x^x or x^^3
x!!! < x^^4
C(x,y) < x^^y // for x,y=>2

C(x,x) > B(x) for x=>3

A(x,x) < A(x) = x↑xx (two argument ackermann vs ackermann number)
A(x) > C(x) for x=>3

g1 = 3^^^^3 = 3↑43
g2 = 3↑g13
gx > A(x) (no catch-up here)
gx+2 > A(A(x+1))

TREE(x) > gx for x=>3
TREE(x+1) > g...gx with x amount of g's (you are gonna have to trust me on this, TREE is ridiculously way faster than just this)

Now that we've placed the cutlery on the table, Lets put that whole salad on a plate and eat our way out from the inside , right to left
note, for those whom it might not be obvious, each subsequent number will be bigger and simpler
C(B(TREE(gA(g65,g65)), B(TREE(gA(g65,g65)))
A(g65,g65) < A(g65)

C(B(TREE(gA(g65)), B(TREE(gA(g65)))
g67 = 3↑g663 = 3↑3↑g6533 )
A(g65) = g65↑g65g65
g67 > A(g65)

C(B(TREE(g67), B(TREE(g67))
gx > A(x) > C(x,x) >B(x)

ggTREE(g67)
TREE(3)>ggg3>g67

ggTREE(TREE(3))
TREE(TREE(3)+1)>gg...TREE(TREE(3)) with TREE(TREE(3)) g's > ggTREE(TREE(3)+1)

Your number is less than TREE(TREE(3)+1), Beaten at page 12 by Deedlit's entry

Rhombic
Posts: 58
Joined: Wed Jan 01, 2014 11:42 pm UTC

### Re: My number is bigger!

defining Primes(k) as the number of prime numbers < k;
Fn is the nth Fibonacci number

define Indigo(a, b, c, d) as the following

w = TREE(a)+c
for r in range(b):
w = (d^TREE((w^w)!)!
for t in range(d):
w = Primes(w!)^(w^Fw)
return n

My number is Indigo(2017, 2017^2017, 2017, 2017^F2017)

Daggoth
Posts: 52
Joined: Wed Aug 05, 2009 2:37 am UTC

### Re: My number is bigger!

n has no value

unless you meant return w maybe?

WarDaft
Posts: 1583
Joined: Thu Jul 30, 2009 3:16 pm UTC

### Re: My number is bigger!

The largest uncontested number is currently Deedlit's. There are two potentially larger numbers, but they are floating around at sizes where you can't hand-wave things that are being hand-waved, and I'll let someone with a sufficient math degree suss that out.

Instead, let's add more chaos. I'm going to propose a very large number, but I don't know how large. I solved a problem that was bugging me about an idea I had for a suggestion.

Worms come in orders now.
An order 0 worm is just a regular worm.
An order k worm is a list of order k-1 worms.
The local head of an order k worm is the highest indexed element of the order k worm, the global head is the local head chosen recursively until you have an integer.
The position of each integer in a worm can be specified as a 1-indexed vector based on the indicies from the groups it is a member of.
For example, in the worm 0101|1010|11 the bolded 0 has a position <2:2>
If the global head is 0, then to decrement an order k worm you:
- if you are in an order 0 worm, chop off the 0, skip the remaining steps, and return the new length l as the vector <l>
- if you are in an order k > 0 worm, decrement the local head to obtain an inspection vector v
2) Duplicate
- let l be the length of the current order k worm, form the inspection vector l:v, decrease l until you reach the first (IE highest) k+1:v such that k:v is an empty cell. Duplicate indicies k+1 through l n times. Return the vector k+1:v
If the global head is greater than 0, then to decrement an order k worm you:
- if you are in an order 0 worm, grow it like a normal worm, return the length d of the dead worm as the vector <d+1>, skip the remaining steps
- if you are in an order k worm, let l be the length of the current order k worm, decrement the local head to obtain inspection vector l:v.
2) Grow
- decrease l until you reach the first (IE highest) k+1:v such that element k:v is less than the current (IE post decrement) global head, or it's empty. Create l-k-1 copies of element l and append them to the current order k worm, which is now of length l2, let d be the first component of vector v, then, for elements k+1 through l-1, slice from element d through to the end of that order k-1 worm and append them pairwise to elements l through to l2-1, return the vector k+1:v

The goal was to embed a Buchholz hydra into a 2-d worm in a way that can be extended to higher dimensions.

An n-multiworm is an n-dimensional worm, where each dimension is of size n, and each cell contains n. I enter a (3-multiworm)-multiworm. I have no idea what scale this is.
All Shadow priest spells that deal Fire damage now appear green.
Big freaky cereal boxes of death.

phillip1882
Posts: 145
Joined: Fri Jun 14, 2013 9:11 pm UTC
Location: geogia
Contact:

### Re: My number is bigger!

busybever(tree(5))
good luck have fun

Daggoth
Posts: 52
Joined: Wed Aug 05, 2009 2:37 am UTC

### Re: My number is bigger!

I have no idea what scale this is.

any rough estimate / insight?

Deedlit
Posts: 91
Joined: Sun Mar 08, 2009 2:55 am UTC

### Re: My number is bigger!

Wardaft, a few questions:

1. Is the k in " decrease l until you reach the first (IE highest) k+1:v such that k:v is an empty cell" a different variable from the k in "order k worm"?

2. The "inspection vector" is just the vector for the current global head, right?

3. I don't understand the "Grow" procedure, in particular the "slice from element d through to the end of that order k-1 worm" part. Could you explain it more thoroughly, perhaps give a few examples showing how the procedure is implemented?

4. How does the Buchholz hydra embed into a 2D worm? (I assume you mean an order 2 worm here.) I wondered if the order 1 subworms of an order 2 worm were meant to be the branches of the Buchholz hydra tree for each leaf node, but the decrementing procedure you describe doesn't seem to match the Buchholz hydra procedure given this embedding.

5. Do you have any argument/intuition why this procedure for order k worms should terminate?

fulvius
Posts: 2
Joined: Tue Jan 06, 2009 9:29 am UTC

### Re: My number is bigger!

Nice posts, deedlit et. al! I am out of my depth, but I'd like to comment and propose a number anyway. At first I thought I was going to be able to beat you by replacing the occurrences of 10 and 100 in the BEAF expression of the highest computable number at Bowers Infinity Scrapers, page, which is meameamealokkapoowa oompa. My thought was that instead of 10 and 100 we could use some other large number like SCG(13) or Loader's number in place of the 10s and 100 in the BEAF notation for oompa and get a bigger but still computable number... But then I noticed something at the end of the article at The Googology wiki for Loader's number. It said, "The final output of (Loader's number) is much larger than TREE(3), SCG(13), and likely anything that can be practically defined by BEAF. It is probably overpowered by finite promise games and greedy clique sequences." Oompa can be practically defined by BEAF so, assuming this is true, then oompa is not as good a starting point as Loader's number.

Next, I looked up Finite promise games and Greedy clique sequence in the Googology wiki and I couldn't understand those articles any better than Deedlit's posts on page 12... But I did notice a statement by Deedlit on page 12 where he says, "The limit of this notation, tsi_0(w_w), is an ordinal of some importance. It was shown to be the termination ordering of some decision problems. (I'm recalling this from one of Harvey Friedman's papers, I'm not sure which.) It's also the complexity of the Buchholz Hydra on finite labelled trees." And I also noticed this on the Bucholz hydra page: "The Buchholz hydra surpasses TREE(n) and SCG(n). It is likely weaker than loader.c as well as numbers from finite promise games."

So, unless I am misunderstanding, it sounds like Deedlit's numbers are on the order of numbers generated by the Buchholz Hydras, which are "likely??" smaller than the output of loader.c and finite promise games?

I think this might beat other numbers in this thread, but I suspect deedlit would be a more qualified mathematician than I am to make that call... but if his iterations remain near the "level" of the Bucholz hydras, and if either loader.c or finite promise games are truly "stronger" than Bucholz hydras in the fast-growing heirarchy, then... my number is bigger!

wabb2t
Posts: 0
Joined: Tue Oct 17, 2017 7:17 pm UTC

### Re: My number is bigger!

fulvius wrote:Nice posts, deedlit et. al! I am out of my depth, but I'd like to comment and propose a number anyway. At first I thought I was going to be able to beat you by replacing the occurrences of 10 and 100 in the BEAF expression of the highest computable number at Bowers Infinity Scrapers, page, which is meameamealokkapoowa oompa. My thought was that instead of 10 and 100 we could use some other large number like SCG(13) or Loader's number in place of the 10s and 100 in the BEAF notation for oompa and get a bigger but still computable number... But then I noticed something at the end of the article at The Googology wiki for Loader's number. It said, "The final output of (Loader's number) is much larger than TREE(3), SCG(13), and likely anything that can be practically defined by BEAF. It is probably overpowered by finite promise games and greedy clique sequences." Oompa can be practically defined by BEAF so, assuming this is true, then oompa is not as good a starting point as Loader's number.

Next, I looked up Finite promise games and Greedy clique sequence in the Googology wiki and I couldn't understand those articles any better than Deedlit's posts on page 12... But I did notice a statement by Deedlit on page 12 where he says, "The limit of this notation, tsi_0(w_w), is an ordinal of some importance. It was shown to be the termination ordering of some decision problems. (I'm recalling this from one of Harvey Friedman's papers, I'm not sure which.) It's also the complexity of the Buchholz Hydra on finite labelled trees." And I also noticed this on the Bucholz hydra page: "The Buchholz hydra surpasses TREE(n) and SCG(n). It is likely weaker than loader.c as well as numbers from finite promise games."

So, unless I am misunderstanding, it sounds like Deedlit's numbers are on the order of numbers generated by the Buchholz Hydras, which are "likely??" smaller than the output of loader.c and finite promise games?

I think this might beat other numbers in this thread, but I suspect deedlit would be a more qualified mathematician than I am to make that call... but if his iterations remain near the "level" of the Bucholz hydras, and if either loader.c or finite promise games are truly "stronger" than Bucholz hydras in the fast-growing heirarchy, then... my number is bigger!

Hello fulvius

By saying that Loader's D() is "likely" faster than Buchholz's BH(), it is meant that, assuming that the program does not contains any bug and indeed outputs what it is supposed to output, then it beats (i.e. eventually dominates) Buchholz's BH(). Similarly, Friedman's promise games are "likely" faster than D() means that IF these functions are well-defined as we believe and if Friedman's results about their speed are correct (if he didn't make any mistake) then FLCI()&co are faster than D().

tl;dr: Friedman's promise games beats Loader's D() which beats Buchholz's BH().
I think Deedlit's function on page 12 does reach BH() or near it, but I'm not sure. It most certainely does not go too far beyond that in any case.

fulvius
Posts: 2
Joined: Tue Jan 06, 2009 9:29 am UTC

### Re: My number is bigger!

wabb2t wrote:Hello fulvius

By saying that Loader's D() is "likely" faster than Buchholz's BH(), it is meant that, assuming that the program does not contains any bug and indeed outputs what it is supposed to output, then it beats (i.e. eventually dominates) Buchholz's BH(). Similarly, Friedman's promise games are "likely" faster than D() means that IF these functions are well-defined as we believe and if Friedman's results about their speed are correct (if he didn't make any mistake) then FLCI()&co are faster than D().

tl;dr: Friedman's promise games beats Loader's D() which beats Buchholz's BH().
I think Deedlit's function on page 12 does reach BH() or near it, but I'm not sure. It most certainely does not go too far beyond that in any case.

Yep that sounds about right to me. I think there are two things to notice here: one is that it's more effective to start from a faster-growing function than it is to cleverly compound and manipulate a slower-growing one to make it seem like it's meaningfully larger. Two is that it's difficult to know for sure which of the known fast-growing functions actually grow the fastest. There is a formal proof, for example, that SCG(13) is larger than TREE(3), but when it comes to finite promise games, there doesn't seem to be as much certainty in the publications and wikis as to how those functions compare to Loader's, etc. It's very possible that these are still open problems, in which case it might not be feasible for us to know which number here is the largest without making all-new breakthroughs in mathematics.

The psychological "wow" factor from nesting and compounding functions seems less significant than the functions we choose to nest. By extension, it seems that putting the seed for D() within a Loader's-number-deep set of nested parentheses is probably a lot less meaningful than the fact that the result is subsequently used as the input for FLCI().

One thing I'd like to point out about loader.c is that it won't successfully output a number on any actual computer... the number grows too large for any available hardware. C is simply the mathematical syntax in which that function is expressed, and so it can be checked for self-consistency and accuracy just as any other problem, function or proof can be checked in any other notation. Still, without actually computing the number it brings us back to that uncertainty: which number is really bigger? We may never know.

Daggoth
Posts: 52
Joined: Wed Aug 05, 2009 2:37 am UTC

### Re: My number is bigger!

Still, without actually computing the number it brings us back to that uncertainty: which number is really bigger? We may never know.

But we may, analyzing the structures and methods upon which each number is built, we can draw a provable conclusion for either A or B being the biggest, even if neither can be actually computed in hardware. If we were to limit the topic to discuss only the (puny) numbers that could ever be computed, the thread would have ended since page 1 ( http://forums.xkcd.com/viewtopic.php?p=179672#p179672 ) . by a poster whose nickname is, perhaps ironically, Ended.
(10^^^10)!
will never be "actually computed"

Yakk
Poster with most posts but no title.
Posts: 11128
Joined: Sat Jan 27, 2007 7:27 pm UTC
Location: E pur si muove

### Re: My number is bigger!

The psychological "wow" factor from nesting and compounding functions seems less significant than the functions we choose to nest.

In fact, the very act of compounding functions is wasteful to the reader.

Find the fastest growing function in the random compounding. Check that the other functions (A) feed it a value bigger than 2, and (B) don't map it back to 1. That is the only function that really matters in the noisy compounding mess.

If someone else has a "slightly" faster growing function, they'll beat it with a small input than yours does with a ridiculous input.

I tried to capture that in my 3 types of large number post above. We have small large numbers, medium ones and big ones.

Small ones are boring, like 10^^^^^^10. Medium ones are something reasonably strong, like the fast growing heirarchy powered by a reasonable ordinal. And then there are the Large ones.

Throwing around "we then pass it to" some other named algorithm is a waste of words. Almost all of the medium and large ones have ways to twerk their definition so they'll grow slightly faster that blow your "call A then call B" out of the water. And in turn, they blow each other out of the water, even when they are hard to work out which grows faster.
One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

Last edited by JHVH on Fri Oct 23, 4004 BCE 6:17 pm, edited 6 times in total.

itaibn
Posts: 142
Joined: Mon Dec 29, 2008 7:06 pm UTC

### Re: My number is bigger!

It's been a long time since I was active here, but I want to show you something I wrote. It's about a system for describing large numbers with precision, somewhat akin to scientific notation but extending to numbers in at the ordinal function regime. Here's a link:

https://itaibn.wordpress.com/2017/11/09/prefix-free-codes-and-ordinals/

The description is pretty bare at the moment, so I may want to write a clearer explanation in the future.
I NEVER use all-caps.

Patashu
Posts: 378
Joined: Mon Mar 12, 2007 8:54 am UTC
Contact:

### Re: My number is bigger!

I think the thing I'm most sad about is that M never managed to get formalized. The idea of automatically generating bigger and bigger ordinals in an explosive way and then iterating and diagonalizing the process just sounds so cool. I guess it's too big to easily grasp though, huh?

As far as big computable numbers/functions (that can be proven to be well-defined) go, it seems hard to beat Buchholz Hydras ( http://googology.wikia.com/wiki/Buchholz_hydra ), Finite promise games ( http://googology.wikia.com/wiki/Finite_promise_games ) and Greedy clique sequence ( http://googology.wikia.com/wiki/Greedy_clique_sequence ) - basically, anything that would be as large as or larger than f_(Takeuti-Feferman–Buchholz ordinal)(x) in the fast growing hierarchy ( http://googology.wikia.com/wiki/Fast-growing_hierarchy , https://en.wikipedia.org/wiki/Large_num ... _sequences , https://en.wikipedia.org/wiki/Ordinal_c ... rd_ordinal ). (EDIT: Actually, I guess the fastest growing computable function is S(n), defined at the end of Beyond Nested Arrays V, a part of Chris Bird's Super Huge Numbers/Bird Array Notation, since it was designed explicitly to build on the strengths of the previous functions and outstrip them at their own game. Nice work! This series also has definitions of various extended Veblen and Ordinal Collapse functions, while covering every step up to them and beyond, which is useful for keeping track of these immense numbers and ordinals. http://www.mrob.com/users/chrisb/index.html )

So I guess the goal of finding a bigger computable number/function would be to find a bigger, computable, countable ordinal, either by constructing it from below or relating it to a proof somehow, which is well beyond my current understanding of large numbers/ordinals.

I don't find uncomputable numbers/functions nearly as interesting, since it starts to not even be clear if they have a well-defined result, and they kind of just feel untethered from the base case of starting out with 1, successorship, addition, multiplication... etc. But as far as those goes, the winner seems to be either Little Bigeddon or Sasquatch, or possibly Oblivion/Utter Oblivion (from http://googology.wikia.com/wiki/Largest ... oogologism ).

---

I thought about this thread (and extremely large numbers in general) again recently when I made a javascript library, break_infinity.js ( https://github.com/Patashu/break_infinity.js ), which is intended to represent numbers as big as 1e(9e15), focusing on performance over accuracy. It was based off of https://github.com/MikeMcl/decimal.js/ with additional code from SpeedCrunch ( https://bitbucket.org/heldercorreia/spe ... ?at=master ) and of course our friend StackOverflow, but the need for total precision (and in fact the ability to represent arbitrary precision at all - the mantissa is now just a Javascript Number) is dropped so that the code can run faster. I made this library to help out an incremental game, Antimatter Dimensions ( https://www.kongregate.com/games/Hevipe ... dimensions ), which as of the latest update allows you to reach numbers as big as 1e800,000. It was finding that decimal.js was slow and hogging CPU - and coding and swapping to break_infinity.js sped time spent in scripts by 4.5x. Not bad! These performance improvements could be applied to any other incremental game that currently uses decimal.js, like Swarm Simulator and True Exponential.

So why does it stop at 1e(9e15)? Because the exponent is stored as a Javascript Number, that is a double precision floating point value, and these cannot represent every possible integer once you get bigger than 2^53-1, or a bit more than 9e15. You could try to go further, but as soon as production slows down enough that you're gaining less than e1 per tick, you'll run into mathematical glitches, either gaining e2 or e0, both of which are unideal. But if that wasn't a concern, we could get as large as 1e(1.8e308) before the exponent becomes Infinity/NaN and the system breaks.

We can go further by replacing the exponent with a big-integer library. I used https://github.com/Yaffle/BigInteger/bl ... Integer.js and made break_break_infinity.js which supports up to 1e(1.8e308). Why not further? Because some intermediate calculations, such as in log, exp and pow cast the exponent to a Javascript Number, and if you get any larger these operations overflow. Not to mention, these operations will need to start being able to accept (and output) Decimal instead of Number. ( https://github.com/Patashu/break_infinity.js/issues/14 ) If you fixed these issues in a compelling manner, let's say that the largest number you can represent is one with GB's worth of digits in its exponent, after that it won't even fit in RAM anymore, so approximately 1e(1e(1e9)). You'd probably run into trouble long before then though, as you'd have many such numbers of that size not just the one, all of them need to fit, and I imagine the big-integer operations are getting slower and slower as they get this titanic.

How do we get even further? At some point we need to make a conscious decision that maybe the exact number of digits in the exponent no longer matters, and rewrite with new assumptions. Another person on the Antimatter Dimensions Discord, SpectralFlame, is in their spare time making a HugeNumber library for Java ( https://github.com/cyip92/HugeNumber/bl ... umber.java ), and testing it out by making a stripped down Antimatter Dimensions clone with buttons like 'square all dimension multipliers'. I haven't seen the code for HugeNumber, but from the explanations it sounds like a HugeNumber's exponent can recursively also be a HugeNumber, so that you can represent very large numbers, basically arbitrarily big power towers, by stacking HugeNumbers inside of HugeNumbers until you get something like Ae(Be(Ce(De(EeF)))). In addition to that, once the tower gets unwieldy enough, it keeps track of only the top exponent and the tower size - which in theory lets it handle numbers up to 10^^1000000. Maybe I should ask for it to get open-sourced, it sounds like a really cool way to do it. Perhaps inspiration for break_break_break_infinity.js?

Obviously numbers that aren't even as big as 3^^^3 were surpassed by the first few pages of this thread, but it's interesting to work with the intersection between huge numbers and programmatic representations. When you're working with numbers that can get as big as x^^y, what kind of game can you write? What kinds of operations does your library optimize for? What kinds of precision requirements do you have, and what kinds of precision guarantees can even be made? How do you print these numbers and present them to the player in a way that they can intuitively grasp their relative magnitudes? How do you compare them to find out if they're equal, nearly equal, bigger or smaller? And so on.

PsiSquared
Posts: 126
Joined: Wed May 09, 2012 6:02 pm UTC

### Re: My number is bigger!

Pataschu,

You could simplify the "Ae(Be(Ce(De(EeF))))" format considerably by forgetting the A,B,C and D and simply using the format eeee(E'eF').

This can be readily extended to any power tower height (i.e. any number of e's).

This is exactly the format used by Robert Munafo's big numbers calculator which is called HyperCalc. It can deal with power towers billions of tens high.

I myself have invented a system that goes much further, but I've never tried to implement it into an actual calculator program. For example, you can write Graham's Number in this notation as:

Graham's Number ~ L2-1-1-1-1-64-3▪3-2-2-1-12-7625597484986-1-12-3638334640023-60...

(note the "64" in there, which tells you how many layers of arrows there are in Graham's number)

Meowers
Posts: 6
Joined: Wed Apr 06, 2016 1:35 am UTC

### Re: My number is bigger!

What's M?

PsiSquared
Posts: 126
Joined: Wed May 09, 2012 6:02 pm UTC

### Re: My number is bigger!

Fulvius' number is ill-defined, because "oompa" (and the higher levels of BEAF in general) is ill-defined.

Also, aren't we way beyond Loader's Number anyway at this point? We're already deep in the realm of what Yakk calls "type-3 Large Numbers". If anyone here ever posted a well-defined number based on proof theory and any ZF variant then Loader (and all variations thereof) has already been beaten.

Friedman's FLCI(n) (for any reasonably large n) might still win... once somebody actually writes a precise definition for it. Friedman himself never did, and only attempted definition I've seen online seems to be wrong (trying to actually work with it gives absurd results).

BTW Is anybody even keeping score? It seems that after the first half dozen pages, the players never reached a consensus regarding which entries were - indeed - largest at the time of their posting.

itaibn
Posts: 142
Joined: Mon Dec 29, 2008 7:06 pm UTC

### Re: My number is bigger!

Patashu: The questions that you discuss in your comment are similar to what I cover in my blog post. As PsiSquared points out, representing huge numbers in a form like "Ae(Be(CeD))" is inefficient: As soon as you have an expression of the form Ae(BeC), since the exponent BeC does not give a complete-precision representation of a natural number the whole expression has uncertainty in its order of magnitude. Therefore the mantissa A cannot provide any additional precision to the expression. Instead the number should be represented in form like exp(BeC) -- this is both more efficient and it is a more faithful description of exactly what is known about the order of magnitude of this number. For larger numbers you may abbreviate exp(...(exp(AeB))...) as exp^n(AeB), where n is an exact integer, prehaps represented using an ordinary bignum library. Once n is so large that it may no longer be represented exactly, then there is no longer any use in including the AeB part, as the imprecision in n swamps the extra precision gained from writing out the AeB part. Then it becomes better to simply express the number as 2^^n, where n uses another huge number representation.

I have created a general system for expressing huge numbers with precision along the same lines as what I described above. It is based on creating prefix-free codes that can give exact representations of numbers, and then truncating these exact representations to get approximate representations that are short enough to store on a computer. The range of my system is about the same as the range of ordinal functions: For any ordinal α, given an ordinal notation for ordinals up to α that satisfies a few nice properties, I can create a corresponding prefix-free code whose truncations can efficient represent numbers up to those described by the αth level of ordinal function hierarchies.

You also raise the question of how to efficient compute with numbers at that range. I've thought about it some, but I don't have a good answer.

PsiSquared: I see you also have a notation system for huge numbers. I'm curious how it works. Also, I second your request that someone update us on what the current record is.
I NEVER use all-caps.

Simply Beautiful Art
Posts: 5
Joined: Sat Feb 10, 2018 2:21 pm UTC

### Re: My number is bigger!

Let capital letters denote sets of ordinals, and greek letters denote ordinals.

I define the following recursively defined set:

D(α,φ) = {0} ∪ {γ+δ, ω^γ, ω_δ, ξ(π,η) | ζ ∈ φ ∧ γ, δ, π, η ∈ D(α,ζ) ∧ η ∈ α} ∪ {sup B | ζ ∈ φ ∧ B ⊂ D(α,ζ)}

And the following recursively defined function:

ξ(π,0) = sup D(0,ω_π)
ξ(π,α) = sup(D(α,ω_π) ∩ ξ(π+1,0)), α > 0

Now define another recursively defined set:

C(α,0) = {0, 1}
C(α,n+1) = {γ+δ, ω^γ, ω_δ, ξ(γ,δ), ψ(γ,η) | γ, δ, η ∈ C(α,n) ∧ η ∈ α}

C(α) = ⋃ C(α,n), n ∈ ω

And the following recursively defined function:

ψ(ß, α) = sup(C(α) ∩ ω_ß)

And finally, the following recursive function:

H(0,n) = n
H(α,n) = H(max(C(sup C(0),n) ∩ α),n+n), α > 0
H(n) = H(sup C(0),n)

My number is H(10^100).

According to my understanding, this will be larger than f_(Ψ_(Ω_1)(0,Ξ[1]))(n) for reasonably small n, where f is the fast growing hierarchy, the subscript is described here, and we use some reasonable choice of fundamental sequences.

BiggggNumber
Posts: 0
Joined: Mon Jan 07, 2019 12:15 am UTC

### Re: My number is bigger!

I call this number the BiggggNumber, and it is defined as thus:
"The largest number that can be well-defined in less than one googol characters of standard English constraint by "well-definedness""
I believe it is valid and all your numbers are provided to find the lower bounds of my number.

The statement does not clearly define the number as it defines a number under a googol char and through naive extension it can be increased, but it defines the definition through which the number may be defined, and such a definition clearly defines the number.

Freddino18
Posts: 31
Joined: Thu Oct 27, 2016 9:40 pm UTC
Location: Disappeared after investigating titles

### Re: My number is bigger!

BiggggNumber wrote:The largest number that can be well-defined in less than one googol characters of standard English constraint by "well-definedness".

I see 2 problems: The first one is that "well-definedness" itself is not well-defined. The second is that you have not provided an adequate definition of well-defined, so the definition of whatever number would have proportionately larger errors (see underline).

Blenders!
GENERATION 23: The first time you see this, copy it into your sig on any forum and add 1 to the generation. Social experiment.
Shriekin' Criminal: Wu Tang, Voodoo Foote: pirate, Amos Quirell: wizard, Sun-Ray Fool: blues, Thomaz Hettkamp: Nazi, farty monkey snatcher, phire AvAtAr: 1337 h4x0r