Your goal is to write a program that prints a number. The bigger the number, the more points you'll get. But be careful! Code length is both limited and heavily weighted in the scoring function. Your printed number will be divided by the cube of the number of bytes you used for your solution.

So, let's say you printed 10000000 and your code is 100 bytes long. Your final score will be 10000000 / 100^3 = 10.

There are other rules to follow, in order to make this challenge a bit harder.

  • You cannot use digits in your code (0123456789);
  • You can use mathematical/physical/etc. constants, but only if they are less than 10. (e.g. You can use Pi ~= 3.14 but you can't use the Avogadro constant = 6e23)
  • Recursion is allowed but the generated number needs to be finite (so infinite is not accepted as a solution. Your program needs to terminate correctly, assuming unbounded time and memory, and generate the requested output);
  • You cannot use the operations * (multiply), / (divide), ^ (power) nor any other way to indicate them (e.g. 2 div 2 is not allowed);
  • Your program can output more than one number, if you need it to do that. Only the highest one will count for scoring;
  • However, you can concatenate strings: this means that any sequence of adjacent digits will be considered as a single number;
  • Your code will be run as-is. This means that the end-user cannot edit any line of code, nor he can input a number or anything else;
  • Maximum code length is 100 bytes.


  1. Steven H., Pyth ≈ fφ(1,0,0)+7(25626)/1000000[1]
  2. Simply Beautiful Art, Ruby ≈ fφ121(ω)(126)[1]
  3. Peter Taylor, GolfScript ≈ fε0+ω+1(17)/1000 [1]
  4. r.e.s., GolfScript ≈ fε0(fε0(fε0(fε0(fε0(fε0(fε0(fε0(fε0(126))))))))) [1]
  5. Simply Beautiful Art, Ruby ≈ fωω2+1(1983)
  6. eaglgenes101, Julia ≈ fω3(127)
  7. col6y, Python 3, ≈ (127→126→...→2→1) / 993 [1][3]
  8. Toeofdoom, Haskell,a20(1) / 993 [1]
  9. Fraxtil, dc, ≈ 15 ↑¹⁶⁶⁶⁶⁶⁵ 15 / 1003 [3]
  10. Magenta, Python, ≈ ack(126,126)/1003 ≈ 10 ↑124 129
  11. Kendall Frey, ECMAScript 6, ≈ 10 3 ↑4 3 / 1003 [1]
  12. Ilmari Karonen, GolfScript, ≈ 10 ↑3 10377 / 183 [1]
  13. BlackCap, Haskell, ≈ 10↑↑65503/1003
  14. recursive, Python, ≈ 2↑↑11 / 953 ≈ 10↑↑8.63297 [1][3]
  15. n.m., Haskell, ≈ 2↑↑7 / 1003 ≈ 10↑↑4.63297 [1]
  16. David Yaw, C, ≈ 10104×1022 / 833 ≈ 10↑↑4.11821 [2]
  17. primo, Perl, ≈ 10(12750684161!)5×227 / 1003 ≈ 10↑↑4.11369
  18. Art, C, ≈ 10102 × 106 / 983 ≈ 10↑↑3.80587
  19. Robert Sørlie, x86, ≈ 102219+32 / 1003 ≈ 10↑↑3.71585
  20. Tobia, APL, ≈ 1010353 / 1003 ≈ 10↑↑3.40616
  21. Darren Stone, C, ≈ 101097.61735 / 983 ≈ 10↑↑3.29875
  22. ecksemmess, C, ≈ 102320 / 1003 ≈ 10↑↑3.29749
  23. Adam Speight, vb.net, ≈ 105000×(264)4 / 1003 ≈ 10↑↑3.28039
  24. Joshua, bash, ≈ 101015 / 863 ≈ 10↑↑3.07282


  1. If every electron in the universe were a qubit, and every superposition thereof could be gainfully used to store information (which, as long as you don't actually need to know what's being stored is theoretically possible), this program requires more memory than could possibly exist, and therefore cannot be run - now, or at any conceiveable point in the future. If the author intended to print a value larger than ≈3↑↑3.28 all at once, this condition applies.
  2. This program requires more memory than currently exists, but not so much that it couldn't theoretically be stored on a meager number of qubits, and therefore a computer may one day exist which could run this program.
  3. All interpreters currently available issue a runtime error, or the program otherwise fails to execute as the author intended.
  4. Running this program will cause irreparable damage to your system.

Edit @primo: I've updated a portion of the scoreboard using a hopefully easier to compare notation, with decimals to denote the logarithmic distance to the next higher power. For example 10↑↑2.5 = 1010√10. I've also changed some scores if I believed to user's analysis to be faulty, feel free to dispute any of these.

Explanation of this notation:

If 0 ≤ b < 1, then a↑↑b = ab.

If b ≥ 1, then a↑↑b = aa↑↑(b-1).

If b < 0, then a↑↑b = loga(a↑↑(b+1)).

  • 15
    \$\begingroup\$ Has someone explicitly said "base 10" yet? \$\endgroup\$ – keshlam Jan 9 '14 at 14:42
  • 1
    \$\begingroup\$ Does the large number count if it's say 12e10 (12*10^10) as 12*10^10? \$\endgroup\$ – hichris123 Jan 9 '14 at 19:36
  • 4
    \$\begingroup\$ I think a better constraint instead of forbidding *, /, and ^, would've been to allow only linear operations, e.g. +, -, ++, --, +=, -=, etc. Otherwise, coders can take advantage of Knuth's up-arrow/Ackermann library functions if made available in their language of choice, which seems like cheating. \$\endgroup\$ – Andrew Cheong Jan 10 '14 at 0:19
  • 12
    \$\begingroup\$ I'm still waiting to see someone earn footnote [4]. \$\endgroup\$ – Brian Minton May 18 '17 at 15:41
  • 1
    \$\begingroup\$ Say, if my program prints 500b, is this invalid? That is, may we ignore all non-numeric things a program prints? And if so, would something like 50r7 count as 507? \$\endgroup\$ – Simply Beautiful Art May 22 '17 at 20:07

71 Answers 71


GolfScript; score at least fε_0+ω+1(17) / 1000

Following r.e.s.'s suggestion to use the Lifetime of a worm answer for this question, I present two programs which vastly improve on his derivation of Howard's solution.

They share a common prefix, modulo the function name:


computes g(g(1)) = g(5) where g(x) = worm_lifetime(x, [x]) grows roughly as fε0 (which r.e.s. notes is "the function in the fast-growing hierarchy that grows at roughly the same rate as the Goodstein function").

The slightly easier (!) to analyse is


.{foo}* maps x to foo^x x.


thus gives g^(g(5)) ( g(5) ); the further 8 levels of iteration are similar to arrow chaining. To express in simple terms: if h_0 = g and h_{i+1} (x) = h_i^x (x) then we calculate h_10 (g(5)).

I think this second program almost certainly scores far better. This time the label assigned to function g is a newline (sic).

}*'n/]*zip n*~}:^~^^^^^^^^^^^^^^^^

This time I make better use of ^ as a different function.

}*'n/]*zip n*~

takes x on the stack, and leaves x followed by a string containing x copies of .{ followed by g followed by x copies of }*; it then evaluates the string. Since I had a better place to burn spare characters, we start with j_0 = g; if j_{i+1} (x) = j_i^x (x) then the first evaluation of ^ computes j_{g(5)} (g(5)) (which I'm pretty sure already beats the previous program). I then execute ^ 16 more times; so if k_0 = g(5) and k_{i+1} = j_{k_i} (k_i) then it calculates k_17. I'm grateful (again) to r.e.s. for estimating that k_i >> fε_0+ω+1(i).

  • \$\begingroup\$ If I'm not mistaken, the number your program computes (call it n) can be written n = f^9 (g(3)), where f(x) = g^(4x) (x), and g(x) is the lifetime of worm [x]. If we treat g as being approximately the same as f_eps_0 in the fast-growing hierarchy, then my "back-of-envelope" calculations show that f_(eps_0 + 2)(9) < n < f_(eps_0 + 2)(10). Of course it's the current winner -- by far. \$\endgroup\$ – r.e.s. Jan 20 '14 at 18:58
  • \$\begingroup\$ @r.e.s., I think that's underestimating it quite a lot. .{foo}* maps x to foo^x (x). If we take h_0 (x) = g^4 (x) and h_{i+1} (x) = h_i^x (x) then the value calculated is h_9 (g(3)). Your f(x) = g^(4x) (x) = h_0^x (x) = h_1 (x). \$\endgroup\$ – Peter Taylor Jan 20 '14 at 19:12
  • \$\begingroup\$ (This pertains to your original program -- I just saw that you've made some edits.) Ohhh... I misunderstood how the * works. It is safe to say that h_0(x) = g^4(x) >> f_eps_0(x); consequently, the relation h_{i+1} (x) = h_i^x (x) effectively defines an "accelerated" fast-growing hierarchy such that h_i(x) >> f_(eps_0 + i)(x). I.e., the computed number h_9 (g(3)) is certainly much greater than f_(eps_0 + 9)(g(3)). As for g(3), I think I can show that it's greater than g_4, the fourth number in the g_i sequence used to define Graham's number (which is g_64). \$\endgroup\$ – r.e.s. Jan 20 '14 at 21:46
  • \$\begingroup\$ @r.e.s., so j_i ~ f_{eps_0 + i}; does that make k_i ~ f_{eps_0 + i omega + i^2}? \$\endgroup\$ – Peter Taylor Jan 20 '14 at 23:50
  • \$\begingroup\$ Given what you wrote, I get k_i ~ f_{ε_0 + ω}^i (k_0). Here's the reasoning: k_{i+1} = j_{k_i} (k_i) = j_ω (k_i) ~ f_{ε_0 + ω} (k_i) ~ f_{ε_0 + ω}^2 (k_{i-1}) ... ~ f_{ε_0 + ω}^{i+1} (k_0), so k_i ~ f_{ε_0 + ω}^i (k_0). A very conservative lower bound on k_i, entirely in terms of the fast-growing hierarchy, is then k_i >> f_{ε_0 + ω}^i (i) = f_{ε_0 + ω + 1} (i). \$\endgroup\$ – r.e.s. Jan 21 '14 at 0:39

C, score = 101097.61735/983 ≈ 10↑↑2.29874984

unsigned long a,b,c,d,e;main(){while(++a)while(++b)while(++c)while(++d)while(++e)printf("%lu",a);}

I appreciate the help in scoring. Any insights or corrections are appreciated. Here is my method:

n = the concatenation of every number from 1 to 264-1, repeated (264-1)4 times. First, here's how I'm estimating (low) the cumulative number of digits from 1 to 264-1 (the "subsequence"): The final number in the subsequence sequence is 264-1 = 18446744073709551615 with 20 digits. Thus, more than 90% of the numbers in the subsequence (those starting with 1..9) have 19 digits. Let's assume the remaining 10% average 10 digits. It will be much more than that, but this is a low estimate for easy math and no cheating. That subsequence gets repeated (264-1)4 times, so the length of n will be at least (0.9×(264-1)×19 + 0.1×(264-1)×10) × (264-1)4 = 3.86613 × 1097 digits. In the comments below, @primo confirms the length of n to be 4.1433x1097. So n itself will be 10 to that power, or 101097.61735.

l = 98 chars of code

score = n/l3 = 101097.61735/983

Requirement: Must run on a 64-bit computer where sizeof(long) == 8. Mac and Linux will do it.

  • 2
    \$\begingroup\$ In C, 'z' is the constant value 122. Right? \$\endgroup\$ – primo Jan 9 '14 at 5:31
  • 1
    \$\begingroup\$ i think printf("%d",n) will make the number much larger. Also, 64-bit computer doesn't mean 64-bit longs, for example Windows use the LLP64 model so long is still 32 bits \$\endgroup\$ – phuclv Jan 9 '14 at 10:59
  • 3
    \$\begingroup\$ it should not matter It does. Signed integer overflow is undefined behavior in C, so it's impossible to predict what will happen when your code is executed. It might violate the finitude requirement. \$\endgroup\$ – Dennis Jan 9 '14 at 14:55
  • 1
    \$\begingroup\$ I think the analysis may be a bit off. The concatenation of 0..2^64-1 is exactly 357823770363079921190 digits long. Repeated (2^64-1)^4 times is 4.1433x10^97. Take 10 to that power is 10^10^97.61735 ≈ 10↑↑3.29875. I think you're claiming a power of ten you don't have (note where 3.866×10^97 became 3.866^10^97. \$\endgroup\$ – primo Jan 15 '14 at 16:06
  • 2
    \$\begingroup\$ Hi @primo. Thanks for putting in the time to check this. Appreciate it. I see what you're saying. My final exponent is wrong. It should be 2.0 instead of 97. 10^10^10^2.00 = 10^10^97.6. I will reflect that in my score now. \$\endgroup\$ – Darren Stone Jan 15 '14 at 21:49

JavaScript 44 chars

This may seem a little cheaty:


Score = 31415926535897932718281828459045 / 44^3 ≈ 3.688007904758867e+26 ≈ 10↑↑2.1536134004

  • 8
    \$\begingroup\$ No rules bent at all: ;) * Can't use 0123456789 [check] * Use any language in which digits are valid characters; [check] * You can use mathematic/physic/etc. constants <10. [check, used 2] * Recursion is allowed but the generated number needs to be finite; [check, no recursion] Can't use *, /, ^; [check] Your program can output more than one number; [check] You can concatenate strings; [check] Your code will be run as-is; [check] Max code length: 100 bytes; [check] Needs to terminate w/i 5 sec [check] \$\endgroup\$ – WallyWest Jan 9 '14 at 23:45
  • \$\begingroup\$ Shave off 2 characters by passing "." to replace instead of /\./g \$\endgroup\$ – gengkev Jan 12 '14 at 21:10
  • 1
    \$\begingroup\$ @gengkev Sadly, only using .replace(".","") only removes the first . character; I have to use the global replace to replace ALL . characters from the string... \$\endgroup\$ – WallyWest Jan 12 '14 at 23:55
  • \$\begingroup\$ You can do m=Math,p=m.PI,e=m.E,s="",alert((p*p*p+s+e*e*e).replace(/\./g,s)) instead, your score is then 3100627668029981620085536923187664 / 63^3 = 1.240017943838551e+28 \$\endgroup\$ – A.M.K Jan 22 '14 at 2:58
  • 1
    \$\begingroup\$ @Cory For one, I'm not going to repeat a constant, otherwise everyone would be using it... Second, I really don't have a second argument... \$\endgroup\$ – WallyWest Jun 19 '14 at 23:28

APL, 10↑↑3.4

Here's my revised attempt:


100 char/byte* program, running on current hardware (uses a negligible amount of memory and regular 32-bit int variables) although it will take a very long time to complete.

You can actually run it on an APL interpreter and it will start printing digits. If allowed to complete, it will have printed a number with 10 × 12345678944 digits.

Therefore the score is 1010 × 12345678944 / 1003 ≈ 1010353 ≈ 10↑↑3.406161


  • ⎕D is a predefined constant string equal to '0123456789'
  • n←⍎⎕D defines n to be the number represented by that string: 123456789 (which is < 231 and therefore can be used as a loop control variable)
  • {⍞←⎕D} will print the 10 digits to standard output, without a newline
  • {⍞←⎕D}⍣n will do it n times ( is the "power operator": it's neither *, /, nor ^, because it's not a math operation, it's a kind of loop)
  • {⍞←n}⍣n⍣n will repeat the previous operation n times, therefore printing the 10 digits n2 times
  • {⍞←n}⍣n⍣n⍣n will do it n3 times
  • I could fit 44 ⍣n in there, so it prints n44 times the string '0123456789'.

*: APL can be written in its own (legacy) single-byte charset that maps APL symbols to the upper 128 byte values. Therefore, for the purpose of scoring, a program of N chars that only uses ASCII characters and APL symbols can be considered to be N bytes long.

  • \$\begingroup\$ Your printed number will be divided for the number of bytes you used for your solution^3., you're dividing by 100 right now. \$\endgroup\$ – ToastyMallows Jan 9 '14 at 18:30
  • 2
    \$\begingroup\$ @ToastyMallows - looks like 100 cubed (100^3) to me. \$\endgroup\$ – Kevin Fegan Jan 9 '14 at 19:36
  • 1
    \$\begingroup\$ I know but it's bytes, not characters. \$\endgroup\$ – ToastyMallows Jan 9 '14 at 20:03
  • 1
    \$\begingroup\$ @ToastyMallows Read the end notes on the answer. \$\endgroup\$ – Simply Beautiful Art May 17 '17 at 13:25
  • \$\begingroup\$ Change {⍞←⎕D} to ⍞← which saves you three bytes that you can use to add one more ⍣n and make ⊢n←⍎⎕D into ⌽⍕n←⍎⎕D for an 80-fold increase. If you allow running with ⎕PP←17 then use ×⍨ instead of ⌽⍕ which almost doubles the number of digits printed. \$\endgroup\$ – Adám Jan 15 at 12:51

Windows 2000 - Windows 8 (3907172 / 23³ = 321)


Save the following to a batch file and run it as Administrator.

CD|Format D:/FS:FAT/V/Q

Output when run on a 4TB drive with the first printed number in bold.

Insert new disk for drive D:
and press ENTER when ready... The type of the file system is NTFS.
The new file system is FAT.
QuickFormatting 3907172M
The volume is too big for FAT16/12.

  • 17
    \$\begingroup\$ Sheer unadulterated genius! \$\endgroup\$ – WallyWest Jan 9 '14 at 0:34
  • 6
    \$\begingroup\$ I think you're supposed to cube the solution length in which I get about 321 as score Your printed number will be divided for the number of bytes you used for your solution^3. \$\endgroup\$ – Cruncher Jan 9 '14 at 14:16
  • 1
    \$\begingroup\$ 77 upvotes, and yet... I note the score is 321... \$\endgroup\$ – Simply Beautiful Art May 19 '17 at 0:54
  • 3
    \$\begingroup\$ @SimplyBeautifulArt, it's not the score, but the journey. :-D \$\endgroup\$ – Hand-E-Food May 19 '17 at 2:04
  • 4
    \$\begingroup\$ Apparently so, one that gave many a good laugh. Now if only we could get this up to the leaderboard...someone needs to earn the "irreparable damage" tag ;) \$\endgroup\$ – Simply Beautiful Art May 19 '17 at 11:10


Don't run this on your calculator (it leaks memory)


Code length = 6 bytes (63=216)

Score = 13,256,072 (2,863,311,531/216)

**Assumes 16 GB free memory on an emulator for Windows*

  • 6
    \$\begingroup\$ one of the rules stated: You cannot use digits in your code (0123456789) I don't know if this counts, dude..? \$\endgroup\$ – WallyWest Jan 9 '14 at 1:55
  • 1
    \$\begingroup\$ @Eliseod'Annunzio Fixed. \$\endgroup\$ – Timtech Jan 9 '14 at 16:42

Powershell (2.53e107976 / 72³ = 6.78e107970 ≈ 10↑↑1.701853371)

This takes far more than 5 seconds to run.

-join(-split(gci \ -r -EA:SilentlyContinue|select Length))-replace"[^\d]"

It retrieves and concatenates the byte length of every file on your current drive. Regex strips out any non-digit characters.

  • \$\begingroup\$ Rule 1 says no digits allowed, you have a 0 in there. \$\endgroup\$ – Kyle Kanos Jan 9 '14 at 3:05
  • \$\begingroup\$ Damn, I do too. There goes my character count. \$\endgroup\$ – Hand-E-Food Jan 9 '14 at 3:54
  • \$\begingroup\$ You can use -ea(+'') to reduce the size ('' converted to a number is 0, which the enum value of SilentlyContinue). You can use \D for the replacement regex which is the same as [^\d]. And you can just use %{$_.Length} instead of select Length which gets rid of the column headers. And then you can get rid of the -split and -replace as well, leaving you with -join(gci \ -ea(+'')-r|%{$_.Length}) which is 37 characters shorter (I also reordered the parameters because the parentheses are needed anyway because of +''). \$\endgroup\$ – Joey Jan 11 '14 at 12:01

C++ - 101 bytes

This runs for exactly 5 seconds - you can't see it, but I have the ASCII character for 5 in there:

int main(){for(int n=time(NULL);time(NULL)<n+'';)std::cout<<n;}

I wouldn't know how large the number is - large enough that my computer wouldn't be able to calculate my score. I ran this program outputting the number into .txt file, and it produced a file of 16.585 MB.

Screenshot of code in text document:

Image of code.

  • \$\begingroup\$ Rule 5 says that you can't use ^ or the equivalent library calls. \$\endgroup\$ – Kyle Kanos Jan 9 '14 at 2:54
  • \$\begingroup\$ Oh dear, guess I'd better re-work it. \$\endgroup\$ – Hosch250 Jan 9 '14 at 3:17
  • \$\begingroup\$ @KyleKanos Fixed, is this better? \$\endgroup\$ – Hosch250 Jan 9 '14 at 3:43
  • \$\begingroup\$ Nope, it has several digits in the code. \$\endgroup\$ – Hand-E-Food Jan 9 '14 at 3:56
  • \$\begingroup\$ @KyleKanos This better now? \$\endgroup\$ – Hosch250 Jan 9 '14 at 4:06

Fortran (6.4243e4926 ≈ 10↑↑2.556279837)

Requires quad-precision library to be installed,

use iso_c_binding;real(c_long_double)a;print*,huge(a);end


(With apologies to Darren Stone)

long n,o,p,q,r;main(){while(--n){while(--o){while(--p){while(--q){while(--r){putchar('z'-'A');}}}}}}

n = 2^64 digit number (9...)

l = 100 chars of code

score ≈ 1e+2135987035920910082395021706169552114602704522356652769947041607822219725780640550022962086936570 ≈ 10↑↑3.2974890744

[ Score = n^5/l^3 = (10^(2^320)-1)/(100^3) = (10^2135987035920910082395021706169552114602704522356652769947041607822219725780640550022962086936576-1)/(10^6) ]

Note that I deserve to be flogged mercilessly for this answer, but couldn't resist. I don't recommend acting like me on stackexchange, for obvious reasons. :-P

EDIT: It would be even harder to resist the temptation to go with something like

long n;main(){putchar('z'-'A');putchar('e');putchar('+');while(--n){putchar('z'-'A');}

...but I suppose that an intended but unspecified rule was that the entire run of digits making up the number must be printed.

  • 1
    \$\begingroup\$ #DEFINE C while(-- long n,o,p,q,r,s,t;main(){Cn){Co){Cp){Cq){Cr{Cs{Ct){putchar('z'-'A');}}}}}}}} \$\endgroup\$ – RobAu Jan 9 '14 at 12:36
  • \$\begingroup\$ @RobAu You're a genius! Make it an answer. I'm sure it'd be the winner. I think you forgot a couple ), but that's okay, because you're only at 96 characters right now. \$\endgroup\$ – Andrew Larsson Jan 9 '14 at 23:14
  • \$\begingroup\$ For everyone that didn't get the sarcasm: see codegolf.stackexchange.com/a/18060/7021 for an even better solution ;) \$\endgroup\$ – RobAu Jan 10 '14 at 13:45

GolfScript 3.673e+374


I think the * is allowed since it indicates string repetition, not multiplication.

Explanation: '~'( will leave 126 (the ASCII value of "~") on the stack. Then copy the number, convert it to a string, and do string repetition 126 times. This gives 126126126126... which is approximately 1.26 e+377. The solution is 7 characters, so divide by 7^3, for a score of approximately 3.673e+374


C (score ≈ 10^20 000 000 000 ≈ 10↑↑3.005558275)

  • ~20 GB output
  • 41 characters (41^3 means nothing)

Despite of rand() the output is deterministic because there is no seed function.

  • \$\begingroup\$ If you are unlucky then your program stops after one iteration and the call for rand() as terminating condition makes it non deterministic. Furthermore calling rand() in every iteration should make it terribly slow. Use something like LONG_MAX defined in limits.h instead. \$\endgroup\$ – klingt.net Jan 9 '14 at 11:24
  • \$\begingroup\$ Ok i take the non deterministic back, because there is no seed like you wrote. \$\endgroup\$ – klingt.net Jan 9 '14 at 11:35
  • 1
    \$\begingroup\$ How about ~' ' instead of rand(), printed with %u ? Two bytes less source, and a higher value. \$\endgroup\$ – MSalters Jan 10 '14 at 9:30

JavaScript 98 chars


generates 2.718e+239622337 ≈ 10↑↑2.9232195202

For score of just slightly more than 2.718e+239622331 ≈ 10↑↑2.9232195197

which is the largest I can make it without the browser crashing.

(console.log(a) will show you the full output)

Don't run these:


would output 2.718+e121333054704 ≈ 10↑↑3.0189898069 (aka 2.718*10^(1.213*10^12) to compare to the longer answer:

more extreme version, if it didn't crash your browser: (80 char)


which would create a number around the same size as e * 10^(10^19) ≈ 10↑↑3.106786869689

Edit: updated code original solution only generated 2.718e+464


Perl - score ≈ 10↑↑4.1


Once again abusing perl's regex engine to grind through an unimaginable amount of combinations, this time using a recursive descent.

In the inner most of the expression, we have a bare . to prevent infinite recursion, and thus limiting the levels of recursion to the length of the string.

What we'll end up with is this:

/((((((((((((((((((((.[ ])*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*/
   ___________________/ \_____________________________________
  /                                                           \
  (((((((((((((((((((.[ ])*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*
   ___________________/ \_____________________________________
  /                                                           \
  (((((((((((((((((((.[ ])*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*)*
   ___________________/ \_____________________________________
  /                    .                                      \

... repeated 671088640 times, for a total of 12750684161 nestings - which quite thoroughly puts my previous attempt of 23 nestings to shame. Remarkably, perl doesn't even choke on this (once again, memory usage holds steady at about 1.3GB), although it will take quite a while before the first print statement is even issued.

From my previous analysis below, it can be concluded that the number of digits output will be on the order of (!12750684161)671088640, where !k is the Left Factorial of k (see A003422). We can approximate this as (k-1)!, which is strictly smaller, but on the same order of magnitude.

And if we ask wolframalpha:

...which barely changes my score at all. I thought for sure that'd be at least 10↑↑5. I guess the difference between 10↑↑4 and 10↑↑4.1 is a lot bigger than you'd think.

Perl - score ≈ 10↑↑4


Abusing the perl regex engine to do some combinatorics for us. The embedded codeblock
(??{print}) will insert its result directly into the regex. Since $_ is composed entirely of 2s (and the result of print is always 1), this can never match, and sends perl spinning through all possible combinations, of which there's quite a few.

Constants used

  • $^F - the maximum system file handle, typically 2.
  • $] - the perl version number, similar to 5.016002.

$_ is then a string containing the digit 2 repeated 671088640 times. Memory usage is constant at about 1.3GB, output begins immediately.


Let's define Pk(n) to be the number of times the print statement is executed, where k is the number of nestings, and n is the length of the string plus one (just because I don't feel like writing n+1 everywhere).

P2(n) = [2, 8, 28, 96, 328, 1120, 3824, 13056, ...]

P3(n) = [3, 18, 123, 900, 6693, 49926, 372615, 2781192, ...]

P4(n) = [4, 56, 1044, 20272, 394940, 7696008, 149970676, 2922453344, ...]

P5(n) = [5, 250, 16695, 1126580, 76039585, 5132387790, 346417023515, 23381856413800, ...]

P6(n) = [6, 1452, 445698, 137050584, 42142941390, 12958920156996, ...]

P7(n) = [7, 10094, 17634981, 30817120348, 53852913389555, ...]

etc. In general, the formula can be generalized as the following:


That is, the Left Factorial of k, i.e. the sum of all factorials less than k (see A003422).

I've been unable to determine closed forms for Dk and Ek, but this doesn't matter too much, if we observe that


With 23 nestings, this gives us an approximate score of:

This should be nearly exact, actually.

But to put this into a notation that's a bit easier to visualize, we can approximate the base of the inner exponent:

and then the exponent itself:

and then ask wolframalpha:

which you may as well just call 10↑↑4 and be done with it.

  • 1
    \$\begingroup\$ So, this will only be a valid solution so long as the version number remains lower than 10? \$\endgroup\$ – Mr Lister Jan 9 '14 at 14:38
  • 3
    \$\begingroup\$ @MrLister Yes. Fortunately, no major version higher than 6 exists, and even that's not considered to be fully 'ready', despite having been originally announced in 2000. \$\endgroup\$ – primo Jan 9 '14 at 14:43
  • \$\begingroup\$ @primo You do realize that you will have to revise this answer once Perl goes into a version number > 10, right? ;) \$\endgroup\$ – WallyWest Jan 10 '14 at 3:10
  • 3
    \$\begingroup\$ @Eliseod'Annunzio If I'm still alive when that day arrives - if ever - I promise to come back and fix it. \$\endgroup\$ – primo Jan 10 '14 at 8:19
  • 2
    \$\begingroup\$ A running solution that surpasses 10↑↑4. That's impressive. Bravo! \$\endgroup\$ – Tobia Jan 19 '14 at 20:16

No more limit on runtime? OK then.

Does the program need to be runnable on modern computers?

Both solutions using a 64-bit compile, so that long is a 64-bit integer.

C: greater than 10(264-1)264, which is itself greater than 1010355393490465494856447 ≈ 10↑↑4.11820744

long z;void f(long n){long i=z;while(--i){if(n)f(n+~z);printf("%lu",~z);}}main(){f(~z);}

88 characters.

To make these formulas easier, I'll use t = 2^64-1 = 18446744073709551615.

main will call f with a parameter of t, which will loop t times, each time printing the value t, and calling f with a parameter of t-1.

Total digits printed: 20 * t.

Each of those calls to f with a parameter of t-1 will iterate t times, printing the value t, and calling f with a parameter of t-2.

Total digits printed: 20 * (t + t*t)

I tried this program using the equivalent of 3-bit integers (I set i = 8 and had main call f(7)). It hit the print statement 6725600 times. That works out to 7^8 + 7^7 + 7^6 + 7^5 + 7^4 + 7^3 + 7^2 + 7 Therefore, I believe that this is the final count for the full program:

Total digits printed: 20 * (t + t*t + t^3 + ... + t^(t-1) + t^t + t^(2^64))

I'm not sure how to calculate (264-1)264. That summation is smaller than (264)264, and I need a power of two to do this calculation. Therefore, I'll calculate (264)264-1. It's smaller than the real result, but since it's a power of two, I can convert it to a power of 10 for comparison with other results.

Does anyone know how to perform that summation, or how to convert (264-1)264 to 10n?

20 * 2^64^(2^64-1)
20 * 2^64^18446744073709551615
20 * 2^(64*18446744073709551615)
20 * 2^1180591620717411303360
10 * 2^1180591620717411303361
divide that exponent by log base 2 of 10 to switch the base of the exponent to powers of 10.
1180591620717411303361 / 3.321928094887362347870319429489390175864831393024580612054756 = 
10 * 10 ^ 355393490465494856446
10 ^ 355393490465494856447

But remember, that's the number of digits printed. The value of the integer is 10 raised to that power, so 10 ^ 10 ^ 355393490465494856447

This program will have a stack depth of 2^64. That's 2^72 bytes of memory just to store the loop counters. That's 4 Billion Terabytes of loop counters. Not to mention the other things that would go on the stack for 2^64 levels of recursion.

Edit: Corrected a pair of typos, and used a more precise value for log2(10).

Edit 2: Wait a second, I've got a loop that the printf is outside of. Let's fix that. Added initializing i.

Edit 3: Dang it, I screwed up the math on the previous edit. Fixed.

This one will run on modern computers, though it won't finish any time soon.

C: 10^10^136 ≈ 10↑↑3.329100567

#define w(q) while(++q)
long a,b,c,d,e,f,g,x;main(){w(a)w(b)w(c)w(d)w(e)w(f)w(g)printf("%lu",~x);}

98 Characters.

This will print the bitwise-inverse of zero, 2^64-1, once for each iteration. 2^64-1 is a 20 digit number.

Number of digits = 20 * (2^64-1)^7 = 14536774485912137805470195290264863598250876154813037507443495139872713780096227571027903270680672445638775618778303705182042800542187500

Rounding the program length to 100 characters, Score = printed number / 1,000,000

Score = 10 ^ 14536774485912137805470195290264863598250876154813037507443495139872713780096227571027903270680672445638775618778303705182042800542187494

  • \$\begingroup\$ Maybe. %u was printing 32-bit numbers even with a 64-bit compile, so I just did the ll out of habit from writing in a 32-bit compiler. \$\endgroup\$ – David Yaw Jan 9 '14 at 19:28
  • \$\begingroup\$ I think %llu would be for long long, and %lu would be correct for long. \$\endgroup\$ – tomlogic Jan 9 '14 at 20:12
  • \$\begingroup\$ Fixed. Force of habit: %u is always 32-bit, %llu is always 64-bit, whether compiling as 32 or 64 bit. However, the solution here requires that long be 64-bit, so you're right, %lu is sufficient. \$\endgroup\$ – David Yaw Jan 9 '14 at 20:42
  • \$\begingroup\$ Your variables on the stack are not guaranteed to be initialized to 0. In the second program, just put them outside of any function. In the first one, you'll have to initialize i. \$\endgroup\$ – Art Jan 10 '14 at 12:39
  • \$\begingroup\$ Also, long overflow is undefined behavior and many modern compilers will just optimize it away if they detect it, you probably want to use unsigned long. \$\endgroup\$ – Art Jan 10 '14 at 12:41

Javascript, 10↑↑↑↑210

100 chars:

z=~~Math.E+'';o={get f(){for(i=z;i--;)z+=i}};o.f;for(i=z;i--;)for(j=z;j--;)for(k=z;k--;)o.f;alert(z)

Based on the observation that maximally iterating f is the optimal way to go, I replaced the 13 calls to f with 3 levels of nested loops calling f, z times each (while f keeps increasing z).

I estimated the score analytically on a piece of paper—I'll type it up if anyone is interested in seeing it.

Improved Score: 10↑↑13

Javascript, in exactly 100 characters, again:


This improves my original answer in three ways—

  1. Defining z on the global scope saves us from having to type o.z each time.

  2. It's possible to define a getter on the global scope (window) and type f instead of o.f.

  3. Having more iterations of f is worth more than starting with a larger number, so instead of (Math.E+'').replace('.','') (=2718281828459045, 27 chars), it's better to use ~~Math.E+'' (=2, 11 chars), and use the salvaged characters to call f many more times.

Since, as analyzed further below, each iteration produces, from a number in the order of magnitude M, a larger number in the order of magnitude 10M, this code produces after each iteration

  1. 210 ∼ O(102)
  2. O(10102) ∼ O(10↑↑2)
  3. O(1010↑↑2) = O(10↑↑3)
  4. O(1010↑↑3) = O(10↑↑4)
  5. O(1010↑↑4) = O(10↑↑5)
  6. O(1010↑↑5) = O(10↑↑6)
  7. O(1010↑↑6) = O(10↑↑7)
  8. O(1010↑↑7) = O(10↑↑8)
  9. O(1010↑↑8) = O(10↑↑9)
  10. O(1010↑↑9) = O(10↑↑10)
  11. O(1010↑↑10) = O(10↑↑11)
  12. O(1010↑↑11) = O(10↑↑12)
  13. O(1010↑↑12) = O(10↑↑13)

Score: ∼101010101016 ≈ 10↑↑6.080669764

Javascript, in exactly 100 characters:

o={'z':(Math.E+'').replace('.',''),get f(){i=o.z;while(i--){o.z+=i}}};o.f;o.f;o.f;o.f;o.f;alert(o.z)

Each o.f invokes the while loop, for a total of 5 loops. After only the first iteration, the score is already over 1042381398144233621. By the second iteration, Mathematica was unable to compute even the number of digits in the result.

Here's a walkthrough of the code:


Start with 2718281828459045 by removing the decimal point from Math.E.

Iteration 1

Concatenate the decreasing sequence of numbers,

  • 2718281828459045
  • 2718281828459044
  • 2718281828459043
  • ...
  • 3
  • 2
  • 1
  • 0

to form a new (gigantic) number,

  • 271828182845904527182818284590442718281828459043...9876543210.

How many digits are in this number? Well, it's the concatenation of

  • 1718281828459046 16-digit numbers
  • 900000000000000 15-digit numbers
  • 90000000000000 14-digit numbers,
  • 9000000000000 13-digit numbers
  • ...
  • 900 3-digit numbers
  • 90 2-digit numbers
  • 10 1-digit numbers

In Mathematica,

In[1]:= 1718281828459046*16+Sum[9*10^i*(i+1),{i,-1,14}]+1
Out[1]= 42381398144233626

In other words, it's 2.72⋅1042381398144233625.

Making my score, after only the first iteration, 2.72⋅1042381398144233619.

Iteration 2

But that's only the beginning. Now, repeat the steps, starting with the gigantic number! That is, concatenate the decreasing sequence of numbers,

  • 271828182845904527182818284590442718281828459043...9876543210
  • 271828182845904527182818284590442718281828459043...9876543209
  • 271828182845904527182818284590442718281828459043...9876543208
  • ...
  • 3
  • 2
  • 1
  • 0

So, what's my new score, Mathematica?

In[2]:= 1.718281828459046*10^42381398144233624*42381398144233625 + Sum[9*10^i*(i + 1), {i, -1, 42381398144233623}] + 1

During evaluation of In[2]:= General::ovfl: Overflow occurred in computation. >>

During evaluation of In[2]:= General::ovfl: Overflow occurred in computation. >>

Out[2]= Overflow[]

Iteration 3


Iteration 4


Iteration 5


Analytical Score

In the first iteration, we calculated the number of digits in the concatenation of the decreasing sequence starting at 2718281828459045, by counting the number of digits in

  • 1718281828459046 16-digit numbers
  • 900000000000000 15-digit numbers
  • 90000000000000 14-digit numbers,
  • 9000000000000 13-digit numbers
  • ...
  • 900 3-digit numbers
  • 90 2-digit numbers
  • 10 1-digit numbers

This sum can be represented by the formula,

        enter image description here

where Z denotes the starting number (e.g. 2718281828459045) and OZ denotes its order of magnitude (e.g. 15, since Z ∼ 1015). Using equivalences for finite sums, the above can be expressed explicitly as

        enter image description here

which, if we take 9 ≈ 10, reduces even further to

        enter image description here

and, finally, expanding terms and ordering them by decreasing order of magnitude, we get

        enter image description here

Now, since we're only interested in the order of magnitude of the result, let's substitute Z with "a number in the order of magnitude of OZ," i.e. 10OZ

        enter image description here

Finally, the 2nd and 3rd terms cancel out, and the last two terms can be dropped (their size is trivial), leaving us with

        enter image description here

from which the first term wins out.

Restated, f takes a number in the order of magnitude of M and produces a number approximately in the order of magnitude of M(10M).

The first iteration can easily be checked by hand. 2718281828459045 is a number in the order of magnitude of 15—therefore f should produce a number in the order of magnitude of 15(1015) ∼ 1016. Indeed, the number produced is, from before, 2.72⋅1042381398144233625—that is, 1042381398144233625 ∼ 101016.

Noting that M is not a significant factor in M(10M), the order of magnitude of the result of each iteration, then, follows a simple pattern of tetration:

  1. 1016
  2. 101016
  3. 10101016
  4. 1010101016
  5. 101010101016

LaTeX sources






  • \$\begingroup\$ My reckoning about your score is based on the observation that f does something like take the number z to its own power. So that's something like ↑↑↑. Of course the score is not 2↑↑↑2, sorry... more like, 2↑↑↑5+1 it seems. Would you agree, should I put that in the leaderboard? \$\endgroup\$ – ceased to turn counterclockwis Jan 10 '14 at 2:33
  • \$\begingroup\$ @leftaroundabout - Thanks for looking into it again. I don't feel comfortable enough with up-arrow notation to say whether your suggestion sounds right or not, but I calculated the order of magnitude of my score (see edit) if you'd like to update the leaderboard with that. \$\endgroup\$ – Andrew Cheong Jan 10 '14 at 8:07
  • \$\begingroup\$ Excellent! I'm not at all firm with up-arrows either. So actually you have "only" a tower of power; I'm afraid that places you two spots lower in the ranking. Kudos for properly analysing the result; my estimations have probably yet more flaws in them, but I felt someone should at least try to get some order in the answers. \$\endgroup\$ – ceased to turn counterclockwis Jan 10 '14 at 9:35
  • 1
    \$\begingroup\$ Your score is wrong. Whenever you start a loop with i=o.z;while(i--)... you are not executing the loop o.z times, because a loop is based on an integer variable and o.z contains a string larger than the largest representable integer, depending on your interpreter's word size. Supposing for your benefit that your interpreter won't barf on converting such a string to int, i will start each time with its largest representable integer value, let's say 2^63, and not with the current value of o.z. \$\endgroup\$ – Tobia Jan 10 '14 at 21:34
  • 2
    \$\begingroup\$ @acheong87 Don't remove yourself, you just have to recompute your score, capping the loop variables to 2^63 or such. PS: leave your analytical score posted here, it's very instructive! \$\endgroup\$ – Tobia Jan 11 '14 at 16:06

GolfScript, score: way too much

OK, how big a number can we print in a few chars of GolfScript?

Let's start with the following code (thanks, Ben!), which prints 126:


Next, let's repeat it 126 times, giving us a number equal to about 1.26126 × 10377:


(That's string repetition, not multiplication, so it should be OK under the rules.)

Now, let's repeat that 378-digit number a little over 10377 times:


You'll never actually see this program finish, since it tries to compute a number with about 10380 ≈ 21140 digits. No computer ever built could store a number that big, nor could such a computer ever be built using known physics; the number of atoms in the observable universe is estimated to be about 1080, so even if we could somehow use all the matter in the universe to store this huge number, we'd still somehow have to cram about 10380 / 1080 = 10300 digits into each atom!

But let's assume that we have God's own GolfScript interpreter, capable of running such a calculation, and that we're still not satisfied. OK, let's do that again!


The output of this program, if it could complete, would have about 1010383 digits, and so would equal approximately 101010383.

But wait! That program is getting kind of repetitive... why don't we turn it into a loop?


Here, the loop body gets run about 10377 times, giving us a theoretical output consisting of about 1010⋰10377 digits or so, where the tower of iterated powers of 10 is about 10377 steps long. (Actually, that's a gross underestimate, since I'm neglecting the fact that the number being repeated also gets longer every time, but relatively speaking that's a minor issue.)

But we're not done yet. Let's add another loop!


To even properly write down an approximation of such numbers requires esoteric mathematical notation. For example, in Knuth up-arrow notation, the number (theoretically) output by the program above should be about 10 ↑3 10377, give or take a few (or 10377) powers of ten, assuming I did the math right.

Numbers like this get way beyond just "incredibly huge", and into the realm of "inconceivable". As in, not only is it impossible to count up to or to write down such numbers (we crossed beyond that point already at the third example above), but they literally have no conceivable use or existence outside abstract mathematics. We can prove, from the axioms of mathematics, that such numbers exist, just like we can prove from the GolfScript specification that program above would compute them, if the limits of reality and available storage space did not intervene), but there's literally nothing in the physical universe that we could use them to count or measure in any sense.

Still, mathematicians do sometimes make use of even larger numbers. (Theoretically) computing numbers that large takes a little bit more work — instead of just nesting more loops one by one, we need to use recursion to telescope the depth of the nested loops. Still, in principle, it should be possible to write a short GolfScript program (well under 100 bytes, I would expect) to (theoretically) compute any number expressible in, say, Conway chained arrow notation; the details are left as an exercise. ;-)

  • 8
    \$\begingroup\$ "...No computer ever built could store a number that big... Correct me if I'm wrong, but I don't think that applies here. Isn't it just repeatedly "storing" and printing 3 digits at a time (?) so no need to store the final result. \$\endgroup\$ – Kevin Fegan Jan 9 '14 at 19:16
  • 11
    \$\begingroup\$ @KevinFegan: That is true — the number is incredibly repetitive, so it would be easy to compress. But then we're no longer really storing the number itself, but rather some abstract formula from which the number may, theoretically, be computed; indeed, one of the most compact such formulas is probably the GolfScript program above that generates it. Also, once we go a step further to the next program, even "printing" the digits one at a time before discarding them becomes impractical — there's simply no known way to carry out that many steps of classical computation in the universe. \$\endgroup\$ – Ilmari Karonen Jan 9 '14 at 22:46
  • \$\begingroup\$ @IlmariKaronen's GolfScript just gave the Googol a wedgie! \$\endgroup\$ – WallyWest Jan 9 '14 at 23:54
  • 5
    \$\begingroup\$ How about actually pushing this to the limit, see how big precisely you can really make it in GolfScript within 100 chars? As it stands, your result is less than Graham's number (which my Haskell solution "approximates"), but as you say GolfScript can probably go even further. \$\endgroup\$ – ceased to turn counterclockwis Jan 10 '14 at 0:55
  • 3
    \$\begingroup\$ @leftaroundabout: I managed to write a Conway arrow notation evaluator in 80 chars of GolfScript, although it doesn't pass all the requirements of this challenge (it uses numeric constants and arithmetic operators). It could probably be improved, but I thought I might pose that as a new challenge. \$\endgroup\$ – Ilmari Karonen Jan 10 '14 at 0:59

C, ??? (91 characters)

main(int d,char**v){long c='\t'-'\b';for(;c;c++)for(d-=d;(*v)[d];d++)printf("%llu",(*v)[d]);}

If I could use ^, I'd write d^=d, but alas.

Run through argv[0] and print its contents as an unsigned long long.Repeat 2long-1 times.

Since argv[0] is the program's path, I'd assume the smallest possible value printed by this program (on Windows) would be A:\ .com with a 32 bit long. I'm not so sure on that though, smaller paths are probably possible.

  • \$\begingroup\$ You can as ^ is xor operator, not exponentiation. \$\endgroup\$ – user75200 Dec 28 '17 at 15:11

ECMAScript 6 - 10^3↑↑↑↑3 / 884736

(3↑↑↑↑3 is G(1) where G(64) is Graham's number)


Output: 10^3↑↑↑↑3


G is the function where G(64) is Graham's number. Input is an integer. Output is a unary string written with 0. Removed for brevity.

K is the Knuth up-arrow function a ↑n b where a is implicitly 3. Input is n, a unary string, and b, a unary string. Output is a unary string.

u is "1".

v is "0000", or G(0)

e is "000".

  • \$\begingroup\$ Maximum code length is 100 bytes; Otherwise this is near unbeatable \$\endgroup\$ – Cruncher Jan 9 '14 at 14:16
  • \$\begingroup\$ @Cruncher Aaah, I missed that \$\endgroup\$ – Kendall Frey Jan 9 '14 at 14:24
  • \$\begingroup\$ Ahh, I hate you now. Everytime I try to fathom the size of Graham's number my head hurts. \$\endgroup\$ – Cruncher Jan 9 '14 at 14:34
  • \$\begingroup\$ also, doesn't Graham's number count as a constant > 10? \$\endgroup\$ – serakfalcon Jan 9 '14 at 14:35
  • 1
    \$\begingroup\$ Now to determine if mine beats Ilmari's. \$\endgroup\$ – Kendall Frey Jan 9 '14 at 15:00

Ruby, probabilistically infinite, 54 characters

x+=x while x.times.map(&:rand).uniq[x/x]
p x

x is initialized to 97. We then iterate the following procedure: Generate x random numbers between 0 and 1. If they are all the same, then terminate and print x. Otherwise, double x and repeat. Since Ruby's random numbers have 17 digits of precision, the odds of terminating at any step are 1 in (10e17)^x. The probability of terminating within n steps is therefore the sum for x=1 to n of (1/10e17)^(2^n), which converges to 1/10e34. This means that for any number, no matter how large, it is overwhelmingly unlikely that this program outputs a lesser number.

Now, of course, the philosophical question is whether a program that has less than a 1 in 10^34 chance of terminating by step n for any n can be said to ever terminate. If we assume not only infinite time and power, but that the program is given the ability to run at increasing speed at a rate that exceeds the rate at which the probability of terminating decreases, we can, I believe, in fact make the probability of terminating by time t arbitrarily close to 1.

  • 3
    \$\begingroup\$ this depends on the number generator which in most languages is unlikely be able to generate 97 times the same number \$\endgroup\$ – ratchet freak Jan 10 '14 at 15:00
  • 1
    \$\begingroup\$ Good point, so in addition to assuming continually rapidly increasing computation power, I also need to assume a perfect source of randomness and a Ruby implementation that uses it. \$\endgroup\$ – histocrat Jan 10 '14 at 19:09

GNU Bash, 10^40964096² / 80^3 ≈ 10↑↑2.072820169

C=$(stat -c %s /) sh -c 'dd if=/dev/zero bs=$C$C count=$C$C|tr \\$((C-C)) $SHLVL'

C = 4096 on any reasonable system. SHLVL is a small positive integer (usually either 1 or 2 depending on whether /bin/sh is bash or not).

64 bit UNIX only:

Score: ~ 10^(40964096409640964096*40964096409640964096) / 88^3

C=$(stat -c %s /) sh -c 'dd if=/dev/zero bs=$C$C$C$C$C count=$C$C$C$C$C|tr \\$((C-C)) $SHLVL'
  • \$\begingroup\$ SHLVL is the level of bash as subbash: bash -c 'bash -c "echo \$SHLVL"' \$\endgroup\$ – F. Hauri Jan 3 '16 at 7:41
  • \$\begingroup\$ stat --printf don't work. Try stat -c %s \$\endgroup\$ – F. Hauri Jan 3 '16 at 7:41
  • \$\begingroup\$ @F.Hauri: --printf works for me but so does -c so that shaved a few bytes. Thanks. \$\endgroup\$ – Joshua Jan 3 '16 at 20:42

Python, 2↑↑11 / 830584 ≈ 10↑↑8.632971 (Knuth up arrow notation)

print True<<(True<<(True<<(True<<(True<<(True<<(True<<(True<<(True<<(True<<True<<True)))))))))

Probably no computer has enough memory to successfully run this, but that's not really the program's fault. With the minimum system requirements satisfied, it does work.

Yes, this is doing bit shifting on boolean values. True gets coerced to 1 in this context. Python has arbitrary length integers.

  • \$\begingroup\$ Your code doesn't run. Only print True<<(True<<(True<<(True<<True<<True))) does, and that outputs a 19k string. \$\endgroup\$ – Gabe Jan 9 '14 at 22:56
  • \$\begingroup\$ What are that minimum system requirements? \$\endgroup\$ – Danubian Sailor Jan 10 '14 at 10:15
  • 8
    \$\begingroup\$ Could you not make it shorter by defining t=True and then using t after? \$\endgroup\$ – Bob Jan 16 '14 at 12:51
  • 1
    \$\begingroup\$ Better yet, just make a loop that does these nestings for you. \$\endgroup\$ – Simply Beautiful Art May 14 '17 at 0:24
  • \$\begingroup\$ This fails for me: $python -c 'print True<<(True<<(True<<(True<<(True<<(True<<(True<<(True<<(True<<(True<<True<<True)))))))))' Traceback (most recent call last): File "<string>", line 1, in <module> OverflowError: long int too large to convert to int \$\endgroup\$ – Brian Minton May 19 '17 at 13:17

JavaScript - 84 Characters - Final Score: 2.082941723E+2886 ≈ 10↑↑2.390912646


(function n(a){b=a.length+'';a.push(b);b.length<Math.PI?n(a):alert(a.join(''))})([])



(2893 digits)


(Calculated using http://keisan.casio.com/calculator)

Output / 84^3 = 2.082941723E+2886

C - 92 bytes (score 1.2842113915e4373822 ≈ 10↑↑2.822224398)

main(){char c='~',n='z'-'A',f=c,g=c;while(--c!=n)while(--f!=n)while(--g!=n)printf("%c",n);}

Wrote this before I found someone already posted a C solution. Oh, well.

This program generates the digit '9' by subtracting the ascii value 'A' from 'z', then repeatedly prints it.

Since the characters wrap around the container values, it actually repeats more than just the simple (126-57)^3 from the character values, it instead wraps around the character cells after subtraction, resulting in repeating the digit '9' 4373828 times. (I'm too tired right now to figure out why that particular number, but I'll edit later)


Haskell, score: (22265536-3)/1000000 ≈ 2↑↑7 ≈ 10↑↑4.6329710779

o=round$sin pi
i=succ o

This program is exactly 100 bytes of pure Haskell code. It will print the fourth Ackermann number, eventually consuming all available energy, matter and time of the Universe and beyond in the process (thus slightly exceeding the soft limit of 5 seconds).


bash script

ls -lR|sed s/[^[:digit:]]//g|tr -d '\n'

Score: Depends on system. For my system: Approx. 10^(9031890.226806)

Here's how I calculated the score...

Script length=39 (L)

Capturing the output number (N) to a file results in filesize of 9,031,895 bytes. The file size (9031895 bytes) is approximately equal to log10(N). (The "actual" log10(N) would be something like: 9031894.99999999####+ (or so).

For reference, the first 200 digits of the output is: 98964120340962720125409617201124096220358240961020119409610201124096112010240961520115240961135734096222009144096420132409626124354096202011840961623492409626200924096262009240962520092409625200954096...

Calculating score:

score=10^( log10(N)-log10(39^3) )
score=10^( log10(N)-log10(59319) )



  • \$\begingroup\$ You are missing a -e in your call to sed \$\endgroup\$ – Bary12 Jul 5 '18 at 8:44
  • \$\begingroup\$ @Bary12 - Unfortunately, I no longer have access to (bash/sed on) that system, so I can't retry the command to verify it, let alone reproduce the same output. I do recall that I would have copy/pasted the command to a bash shell on that system to collect/verify results so I'm fairly confident it worked, as-is, without the -e. I can tell you that it works, with OR WITHOUT the -e on a Windows 7 system, running GNU sed version 4.2.1, although the command needs slight modification on Windows: dir /s|sed "s/[^[:digit:]]//g"|tr -d "\r\n" (continued ---) \$\endgroup\$ – Kevin Fegan Jul 7 '18 at 21:54
  • \$\begingroup\$ @Bary12 --- From --help on GNU sed V 4.2.1 on my Windows 7 system: If no -e, --expression, -f, or --file option is given, then the first non-option argument is taken as the sed script to interpret. All remaining arguments are names of input files; if no input files are specified, then the standard input is read. According to that, the -e is not required in this case. In any case, if you still feel you are correct, please feel free to edit my post to reflect the new command-length, and score. I won't object. \$\endgroup\$ – Kevin Fegan Jul 7 '18 at 22:05
  • \$\begingroup\$ Oh, my bad, I was using Zsh, that actually had problems with the pattern not being inside a string. \$\endgroup\$ – Bary12 Jul 8 '18 at 8:57

dc, 100 characters

[lnA A-=ilbA A-=jlaSalbB A--SbLndB A--SnSnlhxlhx]sh[LaLnLb1+sbq]si[LbLnLasbq]sjFsaFsbFFFFFFsnlhxclbp

Given enough time and memory, this will calculate a number around 15 ↑¹⁶⁶⁶⁶⁶⁵ 15. I had originally implemented the hyperoperation function, but it required too many characters for this challenge, so I removed the n = 2, b = 0 and n >= 3, b = 0 conditions, turning the n = 1, b = 0 condition into n >= 1, b = 0.

The only arithmetic operators used here are addition and subtraction.

EDIT: as promised in comments, here is a breakdown of what this code does:

[            # start "hyperoperation" macro
lnA A-=i     # if n == 0 call macro i
lbA A-=j     # if b == 0 call macro j
laSa         # push a onto a's stack
lbB A--Sb    # push b-1 onto b's stack
LndB A--SnSn # replace the top value on n with n-1, then push n onto n's stack
lhxlhx       # call macro h twice
]sh          # store this macro in h

[            # start "increment" macro (called when n=0, the operation beneath addition)
LaLnLb       # pop a, b, and n
F+sb         # replace the top value on b with b+15
q            # return
]si          # store this macro in i

[            # start "base case" macro (called when n>0 and b=0)
LbLnLa       # pop b, n, and a
sb           # replace the top value on b with a
q            # return
]sj          # store this macro in j

Fsa          # store F (15) in a
Fsb          # store F (15) in b
FFFFFFsn     # store FFFFFF "base 10" (150000+15000+1500+150+15=1666665) in n
lhx          # load and call macro h
lbp          # load and print b

As noted, this deviates from the hyperoperation function in that the base cases for multiplication and higher are replaced with the base case for addition. This code behaves as though a*0 = a^0 = a↑0 = a↑↑0 ... = a, instead of the mathematically correct a*0 = 0 and a^0 = a↑0 = a↑↑0 ... = 1. As a result, it computes values that are a bit higher than they should be, but that's not a big deal since we are aiming for bigger numbers. :)

EDIT: I just noticed that a digit slipped into the code by accident, in the macro that performs increments for n=0. I've removed it by replacing it with 'F' (15), which has the side effect of scaling each increment operation by 15. I'm not sure how much this affects the final result, but it's probably a lot bigger now.

  • \$\begingroup\$ I have no idea what this code does... can only assume it's correct. Perhaps you could explain a little? \$\endgroup\$ – ceased to turn counterclockwis Jan 10 '14 at 12:27
  • \$\begingroup\$ I'll explain the code piece by piece when I have time later tonight. \$\endgroup\$ – Fraxtil Jan 10 '14 at 18:14
  • \$\begingroup\$ Well, I spaced on that explanation, but I've added it now. Hope it clears things up. \$\endgroup\$ – Fraxtil Jan 13 '14 at 4:28
  • \$\begingroup\$ dc-1.06.95-2 terminates immediately, having printed nothing. \$\endgroup\$ – primo Jan 16 '14 at 17:05
  • 1
    \$\begingroup\$ I wouldn't expect it to work on any existing machine, given the magnitude of the value it will try to generate. I have the same version of dc and it segfaults after a few seconds. I'm assuming "theoretically correct" answers are permitted here, since there's no criteria for resource consumption. \$\endgroup\$ – Fraxtil Jan 16 '14 at 19:16

Haskell - Ackermann function applied to its result 20 times - 99 characters

This is the best haskell solution I can come up with based on the ackermann function - you may notice some similarities to n.m.'s solution, the i=round$log pi was inspired from there and the rest is coincidence :D

i=round$log pi
a n=n?n

It runs the ackermann function on itself 20 times, starting at one, the sequence being

  • 1,
  • 3,
  • 61,
  • a(61,61),
  • a(a(61,61),a(61,61)) --- we will call this a2(61), or a4(1) ---
  • a3(61)
  • ...
  • a18(61), or a20(1). I think this is approximately g18 (see below).

As for the estimation, wikipedia says:

a(m,n) = 2↑m-2(n+3) - 3

From this we can see a3(1) = a(61,61) = 2↑5964 + 3, which is clearly greater than g1 = 3↑43, unless the 3 at the start is far more important than I think. After that, each level does the following (discarding the insignificant constants in an):

  • gn = 3↑gn-13
  • an ~= 2↑an-1(an-1)

If these are approximately equivalent, then a20(1) ~= g18. The final term in an, (an-1) is far greater than 3, so it is potentially higher than g18. I'll see if I can figure out if that would boost it even a single iteration and report back.

  • \$\begingroup\$ Your analysis is correct and g<sub>18</sub> is a good approximation. \$\endgroup\$ – Simply Beautiful Art Jun 20 '17 at 17:37

vb.net (100c)

vb.net has a 36c minimum to all a basic program to run. So I not include this in the character count.

Module M
Dim a=MinValue,z=MaxValue
Sub Main()
For c=a To z
For w=a To z
For t=a To z
For f=a To z
Next f,t,w,c
End Sub
End Module

Note it'll need a machine with cosmos load of memory, but supposing that be true. The result is expressed as roman numerals (No where in the rules did it state it wasn't allowed)

I think the value is ((((5000 ^ (2^64))^(2^64))^(2^64))^(2^64))

or as express in Power to 10 representation. 10^(10^(10^1.890039430542323))


Change the M to Z and the 5000 is now 10000. (Medieval)

Version 2 (100c)

Module M
Dim a=MinValue,z=MaxValue
Sub Main()
End Sub
Sub R(n)
For f=a To z
Write(New String("Z",&HFFFFFFF))
If n>a Then R(n-1)
End Sub
End Module

I think the follow is correct for the outputted number

Z = 200

A = (2^64)

B = (2^28)-1

C = Z^B

D = ((A!)^A)

N = C^D

I think N = 101010101.600064490609157

Version 3 (100c) removed the -1

Module M
Dim a=MinValue,z=MaxValue
Sub Main()
End Sub
Sub R(n)
For f=a To z
Write(New String("Z",&HFFFF))
If n>a Then R(n+True)
End Sub
End Module

N= (200216-1)264!264 = ~101010101.600064490609157

  • \$\begingroup\$ If n>a Then R(n-1) you are using digits in your code. Plus, I would say that Z and/or M can be seen as constants...? I think it's bending the rules, but not breaking them. \$\endgroup\$ – Vereos Jan 10 '14 at 15:07
  • \$\begingroup\$ @Vereos BLEEP! Now I have find a way to subtract one, without using one. \$\endgroup\$ – Adam Speight Jan 10 '14 at 15:13
  • \$\begingroup\$ I'm fairly certain the score here should be 10^(5000*(2^64)^4). Nesting two for loops from 1..10 does not execute 10^10 times, but only 10*10 times. \$\endgroup\$ – primo Jan 15 '14 at 16:26
  • \$\begingroup\$ @primo the score I'm is the Version 3 one. \$\endgroup\$ – Adam Speight Jan 16 '14 at 19:52

C, 10^10^2485766 ≈ 10↑↑3.805871804

unsigned a['~'<<'\v'],l='~'<<'\v',i,z;main(){while(*a<~z)for(i=l;printf("%u",~z),i--&&!++a[i];);}

We create an array of 258048 unsigned integers. It couldn't be unsigned longs because that made the program too long. They are unsigned because I don't want to use undefined behavior, this code is proper C (other than the lack of return from main()) and will compile and run on any normal machine, it will keep running for a long time though. This size is the biggest we can legally express without using non-ascii characters.

We loop through the array starting from the last element. We print the digits of 2^32-1, increment the element and drop the loop if the element hasn't wrapped to 0. This way we'll loop (2^32 - 1)^254048 = 2^8257536 times, printing 10 digits each time.

Here's example code that shows the principle in a more limited data range:

#include <stdio.h>
unsigned int a[3],l=3,i,f;

main(int argc, char *argc){
        while (*a<4) {
        for (i = l; i-- && (a[i] = (a[i] + 1) % 5) == 0;);
            for (f = 0; f < l; f++)
                printf("%lu ", a[f]);

The result is roughly 10^10^2485766 divided by a million which is still roughly 10^10^2485766.

  • \$\begingroup\$ Best C implementation, by far. Why use 5 variables, when you can use an array of 258048? \$\endgroup\$ – primo Jan 16 '14 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.