20
2
As a follow up to Shortest terminating program whose output size exceeds Graham's number and Golf a number bigger than TREE(3), I present a new challenge.
Loader's number is a very large number, that is kind of hard to explain (since it was itself the result of a code golfing exercise with a flexible goal). There is a definition and explanation here, but for the purposes of self-containment, I will attempt to explain it later in this post as well.
The algorithm Ralph Loader used produces one of the largest numbers of any (computable) algorithm ever written! Indeed, Loader's number is the largest "computable" number on the Googology Wiki. (By "computable" number, they mean a number defined in terms of a computation.) That means that if answer produces a number larger than Loader's number in an interesting way (i.e. not just Loader's number+1), you could go down in Googology history! That being said, programs that produce something like Loader's number+1 are definitely valid answers and contenders to this question; just don't expect any fame.
Your job is to create a terminating program that produces a number larger than Loader's number. This is code-golf, so the shortest program wins!
- You aren't allowed to take input.
- Your program must eventually terminate deterministically but you can assume the machine has infinite memory.
- You may assume your language's number type can hold any finite value but need to explain how this exactly works in your language (ex: does a float have infinite precision?)
- Infinities are not allowed as output.
- Underflow of a number type throws an exception. It does not wrap around.
- You need to provide an explanation of why your number is so big and an ungolfed version of your code to check if your solution is valid (since there is no computer with enough memory to store Loader's number).
So here is an explanation of Loader's number. See http://googology.wikia.com/wiki/Loader%27s_number and the links therein for more precise details. In particular, it contains a program that produces Loader's number exactly (by definition).
The calculus of constructions is essentially a programming language with very particular properties.
First of all, every syntactically valid program terminates. There are no infinite loops. This will be very useful, because it means that if we run an arbitrary calculus of constructions program, our program will not get stuck. The problem is that this implies the calculus of constructions is not Turing complete.
Second of all, among non-Turing complete languages, it is one of the most powerful. Essentially, if you can prove that a Turing machine will halt on every input, you can program a function in the calculus of constructions that will simulate it. (This does not make it turing complete, because there are halting turing machines that you can not prove are halting.)
Loader's number is essentially a busy beaver number for the calculus of constructions, which is possible to compute since all coc programs terminate.
In particular, loader.c defines a function called D
. Approximately, D(x)
iterates over all bit-strings less than x
, interprets them as a coc programs, runs the syntactically valid ones, and concatenates the results (which will also be bitstrings). It returns this concatenation.
Loader's number is D(D(D(D(D(99)))))
.
A more readable copy of the code from the googolology wiki
int r, a;
P(y,x){return y- ~y<<x;}
Z(x){return r = x % 2 ? 0 : 1 + Z (x / 2 );}
L(x){return x/2 >> Z(x);}
S(v,y,c,t){
int f = L(t);
int x = r;
return f-2 ? f>2 ? f-v ? t-(f>v)*c : y : P(f,P(S(v,y,c,L(x)), S(v+2,t=S(4,13,-4,y),c,Z(x)))) : A(S(v,y,c,L(x)),S(v,y,c,Z(x)));
}
A(y,x){return L(y)-1 ? 5<<P(y,x) : S(4,x,4,Z(r));}
D(x)
{
int f;
int d;
int c=0;
int t=7;
int u=14;
while(x&&D(x-1),(x/=2)%2&&(1)){
d = L(L(D(x))),
f = L(r),
x = L(r),
c - r||(L(u)||L(r)-f||(x/=2)%2&&(u=S(4,d,4, r),t=A(t,d)),f/2&(x/=2)%2&&(c=P(d,c),t=S(4,13,-4,t),u=S(4,13,-4,u))),
c&&(x/=2)%2&&(t=P(~u&2|(x/=2)%2&&(u=1<<P(L(c),u)),P(L(c),t)),c=r)
u/2&(x/=2)%2&&(c=P(t,c),u=S(4,13,-4,t),t=9);
}
return a = P( P( t, P( u, P( x, c)) ),a);
}
main(){return D(D(D(D(D(99)))));}
You know Googology Wiki? I'm MilkyWay90 there! – MilkyWay90 – 2018-12-03T23:39:35.230
@MilkyWay90 oh, cool. – PyRulez – 2018-12-03T23:57:07.660
6I would advise against downvoting this for similarity to the TREE(3) question: Loader's number is so much larger than TREE(3) that new and interesting approaches are required. – lirtosiast – 2018-12-04T01:00:07.810
@Spitemaster Why do you say that? Since this is [tag:code-golf], you need to beat the other answers to be competitive. So if someone else posts a 512 byte answer, you have to beat 512 bytes to win. It's not just whoever posts an answer first. (Also, for the sake of pendantory, the original program is not valid, since answers need to produce a number larger than Loader's number.) – PyRulez – 2018-12-04T01:16:09.163
@Spitemaster Some people also participate in languages simply to try and get the minimum possible for that language – fəˈnɛtɪk – 2018-12-04T02:56:55.150
The thing is the only interesting answers would be if someone discovers and proves a larger number than loader's number (which isnt just loader's number +x) or if someone uses a language which it is really hard to implement loader's number in. – fəˈnɛtɪk – 2018-12-04T03:10:11.623
2@fəˈnɛtɪk Well, printing Loader's number + 1 is still interesting from a code golf perspective (for example, can you beat the original 512 bytes?) There are also some natural generalizations of loader's number that might be easier to implement (for example, using ZFC instead of CoC). Also, Greedy clique sequences or finite promise games could be used. – PyRulez – 2018-12-04T03:24:05.053
2Unfortunately, as I don't understand the construction of Loader's number and there does not seem to be known upper bounds in terms of the fast growing hierarchy, I cannot give any good answers here. I believe that most answers will be either extensions of Loader's number or things such as the greedy clique sequences and finite promise games... – Simply Beautiful Art – 2018-12-04T12:33:34.660
1@SimplyBeautifulArt Oh boy, if you don't understand it, that doesn't bode well for this challenge. :P I could try explaining it in more detail to you in chat, but I also do not know any hierarchy upper bounds. – PyRulez – 2018-12-04T16:36:22.477
1@SimplyBeautifulArt In particular, since Loader's constant was specifically chosen to try to be the biggest number generated by a certain amount of code (where as Graham's number and TREE(3) at just mathematically interesting numbers that just so happen to be large), I think most answers will just be Loader's number + 1. – PyRulez – 2018-12-04T16:38:23.050
I added a somewhat more readable copy of the code from the wiki to make it easier to implement loader's number if nothing else – fəˈnɛtɪk – 2018-12-05T01:47:45.840
@fəˈnɛtɪk thanks – PyRulez – 2018-12-05T01:48:54.903
@fəˈnɛtɪk Also see https://github.com/rcls/busy
– PyRulez – 2018-12-05T15:49:19.6371Yeah. To make the point even more obviously, Loader's number is the last entry given as a number produced by a computable function in the Googology wikia i.e. there are no non-trivial computable functions that beat it. – Simply Beautiful Art – 2018-12-05T20:20:20.567
@SimplyBeautifulArt There are, just no one has made numbers out of them, check e.g. finite promise games
– Wojowu – 2018-12-24T14:31:30.350Both greedy clique sequences and finite promise games look very difficult to write an algorithm for. I think for now this is likely going to be a game of who can make a slightly modified Loader's Number implementation in the least bytes – ThePlasmaRailgun – 2019-05-17T22:02:20.547
Lately, p進大好きbot posted a computable function that reached f_PTO(ZFC) in FGH on Googology Wiki. I doubt anyone could write it shorter than loader.c and translationa – Naruyoko – 2019-09-08T14:53:15.353
I'm assuming that this can't be answered with a trivial
unsigned long x[-1U/32],c;f(){while(c<-1UL)while(++x[c])x[c+1]++,x[c+1]*=x[c];c++;}
? – S.S. Anne – 2020-01-18T00:54:50.080