12
4
Some of you may be familiar with the BigNum Bakeoff, which ended up quite interestingly. The goal can more or less be summarized as writing a C program who's output would be the largest, under some constraints and theoretical conditions e.g. a computer that could run the program.
In the same spirit, I'm posing a similar challenge open to all languages. The conditions are:
Maximum 512 bytes.
Final result must be printed to STDOUT. This is your score. If multiple integers are printed, they will be concatenated.
Output must be an integer. (Note: Infinity is not an integer.)
No built-in constants larger than 10, but numerals/digits are fine (e.g. Avogadro's constant (as a built-in constant) is invalid, but 10000 isn't.)
The program must terminate when provided sufficient resources to be run.
The printed output must be deterministic when provided sufficient resources to be run.
You are provided large enough integers or bigints for your program to run. For example, if your program requires applying basic operations to numbers smaller than 101,000,000, then you may assume the computer running this can handle numbers at least up to 101,000,000. (Note: Your program may also be run on a computer that handles numbers up to 102,000,000, so simply calling on the maximum integer the computer can handle will not result in deterministic results.)
You are provided enough computing power for your program to finish executing in under 5 seconds. (So don't worry if your program has been running for an hour on your computer and isn't going to finish anytime soon.)
No external resources, so don't think about importing that Ackermann function unless it's a built-in.
All magical items are being temporarily borrowed from a generous deity.
Extremely large with unknown limit
- Steven H, Pyth f3+B³F+ω²(25626)
where B³F is the Church-Kleene ordinal with the fundamental sequence of
B³F[n] = B³F(n), the Busy Beaver BrainF*** variant
B³F[x] = x, ω ≤ x < B³F
Leaderboard:
Simply Beautiful Art, Ruby fψ0(X(ΩM+X(ΩM+1ΩM+1)))+29(999)
Steven H, Pyth fψ(ΩΩ)+ω²+183(25627!)
Leaky Nun, Python 3 fε0(999)
fejfo, Python 3 fωω6(fωω5(9e999))
Steven H, Python 3 fωω+ω²(99999)
Simply Beautiful Art, Ruby fω+35(9999)
i.., Python 2, f3(f3(141))
Some side notes:
If we can't verify your score, we can't put it on the leaderboard. So you may want to expect explaining your program a bit.
Likewise, if you don't understand how large your number is, explain your program and we'll try to work it out.
If you use a Loader's number type of program, I'll place you in a separate category called "Extremely large with unknown limit", since Loader's number doesn't have a non-trivial upper bound in terms of the fast growing hierarchy for 'standard' fundamental sequences.
Numbers will be ranked via the fast-growing hierarchy.
For those who would like to learn how to use the fast growing hierarchy to approximate really large numbers, I'm hosting a Discord server just for that. There's also a chat room: Ordinality.
Similar challenges:
Golf a number bigger than TREE(3)
Shortest terminating program whose output size exceeds Graham's number
For those who want to see some simple programs that output the fast growing hierarchy for small values, here they are:
Ruby: fast growing hierarchy
#f_0:
f=->n{n+=1}
#f_1:
f=->n{n.times{n+=1};n}
#f_2:
f=->n{n.times{n.times{n+=1}};n}
#f_3:
f=->n{n.times{n.times{n.times{n+=1}}};n}
#f_ω:
f=->n{eval("n.times{"*n+"n+=1"+"}"*n);n}
#f_(ω+1):
f=->n{n.times{eval("n.times{"*n+"n+=1"+"}"*n)};n}
#f_(ω+2):
f=->n{n.times{n.times{eval("n.times{"*n+"n+=1"+"}"*n)}};n}
#f_(ω+3):
f=->n{n.times{n.times{n.times{eval("n.times{"*n+"n+=1"+"}"*n)}}};n}
#f_(ω∙2) = f_(ω+ω):
f=->n{eval("n.times{"*n+"eval(\"n.times{\"*n+\"n+=1\"+\"}\"*n)"+"}"*n);n}
etc.
To go from f_x
to f_(x+1)
, we add one loop of the n.times{...}
.
Otherwise, we're diagonalizing against all the previous e.g.
f_ω(1) = f_1(1)
f_ω(2) = f_2(2)
f_ω(3) = f_3(3)
f_(ω+ω)(1) = f_(ω+1)(1)
f_(ω+ω)(2) = f_(ω+2)(2)
f_(ω+ω)(3) = f_(ω+3)(3)
etc.
Do numerals count as built-in constants? – PyRulez – 2017-11-24T22:34:32.860
@PyRulez Nope, they don't count as built-ins – Simply Beautiful Art – 2017-11-24T22:37:06.063
3
@CloseVoters How can this be too broad... Well, asking the user to output one number in infinitely many numbers is not the same as asking the user to choose one of infinitely many tasks to do. To be fair this question ask the user to do the same thing too. 4 close votes as too broad already...
– user202729 – 2017-11-26T02:13:53.567@user202729 Actually, that's false. There's only finitely many valid programs outputting finitely many numbers, so it's one out of x, for some very large x. – Simply Beautiful Art – 2017-11-26T02:17:22.967
So the other question is even more broad. This question only have
<256⁵¹³ × (number of programming languages)
possible answers, which is way less than infinity. – user202729 – 2017-11-26T02:24:49.113@user202729 I suppose one would say that it's broader to have an unknown limit to aim for as opposed to having a specific value one is trying to beat. – Simply Beautiful Art – 2017-11-26T12:35:58.303
Since the program finishes in under 5 seconds, can we assume the tick rate scales accordingly? That is: the speed of computation is raised, instead of made more efficient? – Οurous – 2017-12-09T01:33:52.193
1@Οurous Yes, you may assume that. But realize that when your program is given more resources, including faster computation, the output must still be deterministic. – Simply Beautiful Art – 2017-12-09T01:40:57.073
1I stated in the other comment section why I think the bounded Brainfuck Busy Beaver function will be exponential, but I'd like to add that more generally, I don't think the Church-Kleene ordinal will be the appropriate level for any computer program. A function one can code with a program are computable, and so should fall into the provably recursive functions of some sufficiently strong recursive sound theory. That theory will have a recursive proof theoretic ordinal, and that function will be below that ordinal in the FGH, assuming reasonable fundamental sequences. – Deedlit – 2017-12-13T06:28:01.577
1Of course the actual Busy Beaver function cannot be coded into program (hypercomputational languages aside), and restricted Busy Beaver functions that can be programmed must by necessity be much slower growing. – Deedlit – 2017-12-13T06:30:10.717