# Largest number in ten bytes of code [closed]

Your goal is to print (to the standard output) the largest number possible, using just ten characters of code.

• You may use any features of your language, except built-in exponentiation functions.
• Similarly, you may not use scientific notation to enter a number. (Thus, no 9e+99.)
• The program must print the number without any input from the user. Similarly, no reading from other files, or from the Web, and so on.
• Your program must calculate a single number and print it. You can not print a string, nor can you print the same digit thousands of times.
• You may exclude from the 10-character limit any code necessary to print anything. For example, in Python 2 which uses the print x syntax, you can use up to 16 characters for your program.
• The program must actually succeed in the output. If it takes longer than an hour to run on the fastest computer in the world, it's invalid.
• The output may be in any format (so you can print 999, 5e+100, etc.)
• Infinity is an abstract concept, not a number. So it's not a valid output.
• Did you look at these two? codegolf.stackexchange.com/questions/185/… codegolf.stackexchange.com/questions/18028/… Jun 13, 2014 at 13:35
• What do you exactly mean by "calculate". Also, If it takes longer than an hour to run on any computer in the world, it's invalid. is not objective. I could (theoretically) manufacture a computer that takes an hour to change one T-state Jun 13, 2014 at 13:37
• Does bit-shift count as an exponentiation operator since it is equivalent to * 2^x ? Jun 13, 2014 at 16:08
• The fact that the time limit depends on the performance of the fastest computer in the world makes it impossible for us to determine the set of valid answers... I don't really like that Jun 13, 2014 at 19:45
• Exponentiation functions are not allowed, but ackermann function is allowed? That seems really arbitrary. It remains unclear why a symbolic manipulation is considered "calculating" the number. Jul 7, 2015 at 13:12

# Perl, >1.96835797883262e+18

time*time


Might not be the largest answer... today! But wait enough millennia and it will be!

Edit:

To address some of the comments, by "enough millenia," I do in fact mean n100s of years.

To be fair, if the big freeze/heat death of the universe is how the universe will end (estimated to occur ~10100 years), the "final" value would be ~10214, which is certainly much less than some of the other responses (though, "random quantum fluctuations or quantum tunneling can produce another Big Bang in 101056 years"). If we take a more optimistic approach (e.g. a cyclic or multiverse model), then time will go on infinitely, and so some day in some universe, on some high-bit architecture, the answer would exceed some of the others.

On the other hand, as pointed out, time is indeed limited by the size of integer/long, so in reality something like ~0 would always produce a larger number than time (i.e. the max time supported by the architecture).

This wasn't the most serious answer, but I hope you guys enjoyed it!

• Upvoted because I like the eventuality
– Tim
Jun 13, 2014 at 18:40
• Won't time wrap around and return a small number at some point? Depends on whether it's 32-bit or 64-bit perl I guess Jun 13, 2014 at 20:48
• 1000 years ~ 3e10 seconds, so you'll still be hovering around 1e21 as your output. Perhaps if you waited 1e50 years, you might start competing against the other answers? Jun 14, 2014 at 2:19
• Do you pronounce this "time times time"? :-) (hi Timwi!) Jun 16, 2014 at 14:01
• Is the time on death heat of the universe accounting for daylight savings? You could earn a few more seconds of existence. Jun 17, 2014 at 17:35

# Wolfram ≅ 2.003529930 × 1019728

Yes, it's a language! It drives the back-end of the popular Wolfram Alpha site. It's the only language I found where the Ackermann function is built-in and abbreviated to less than 6 characters.

In eight characters:

$ack(4,2) 200352993...719156733  Or ≅ 2.003529930 × 1019728 ack(4,3), ack(5,2) etc. are much larger, but too large. ack(4,2) is probably the largest Ackermann number than can be completely calculated in under an hour. Larger numbers are rendered in symbolic form, e.g.: $ ack(4,3)

2↑²6 - 3 // using Knuth's up-arrow notation


The rules say any output format is allowed, so this might be valid. This is greater than 101019727, which is larger than any of the other entries here except for the repeated factorial.

However,

$ack(9,9) 2↑⁷12 - 3  is larger than the repeated factorial. The largest number I can get in ten characters is: $ ack(99,99)

2↑⁹⁷102 - 3


This is insanely huge, the Universe isn't big enough to represent a significant portion of its digits, even if you took repeated logs of the number.

• Not bad, but it's no match for my ack(4,2)+1 solution. Jun 13, 2014 at 21:58
• ack(4,2)+2, I WIN
– user18660
Jun 13, 2014 at 22:07
• I think you won. Jun 15, 2014 at 17:34
• @Kyle, Yimin There are lots of misleading statements in this post and the comments under it. This is not the Wolfram Language, and not what's used as the backend of W|A. It is simply "natural language" input to Wolfram|Alpha. In the Wolfram Language ack(4,2) is invalid input. W|A's natural language input shouldn't even count as a programming language. It is not Turing complete, and you can't write even basic programs in it such as Euclid's algorithm. For this reason I don't think this is a valid answer any more than a Google query would be. Jun 16, 2014 at 13:48
• The Wolfram Language is the programming language used in Mathematica, documented here. Wolfram|Alpha takes natural language as input, not the Wolfram Language. Jun 16, 2014 at 13:49

# Python2 shell, 3,010,301 digits

9<<9999999


Calculating the length: Python will append a "L" to these long numbers, so it reports 1 character more than the result has digits.

>>> len(repr( 9<<9999999 ))
3010302


First and last 20 digits:

40724177878623601356... ...96980669011241992192

• Darn it! This showed up whilst I was writing the same answer Jun 13, 2014 at 15:05
• That's really just 9 * 2**9999999, so one could argue it uses exponentiation. Jun 13, 2014 at 15:29
• Wait, ***built-in*** exponentiation functions are not allowed so this might slip under the rules. +1 Jun 13, 2014 at 15:53
• Mathematical way of computing the length: floor(log10(9 * 2**9999999))+1 Jun 13, 2014 at 18:09
• 9<<(9<<99) is a lot bigger, if it terminates. Jun 14, 2014 at 23:16

# CJam, 2 × 10268,435,457

A28{_*}*K*


This computes b, defined as follows:

• a0 = 10

• an = an - 12

• b = 20 × a28

$time cjam <(echo 'A28{_*}*K*') | wc -c Real 2573.28 User 2638.07 Sys 9.46 268435458  ### Background This follows the same idea as Claudiu's answer, but it isn't based on it. I had a similar idea which I posted just a few minutes after he posted his, but I discarded it since it didn't come anywhere near the time limit. However, aditsu's suggestion to upgrade to Java 8 and my idea of using powers of 10 allowed CJam to calculate numbers beyond the reach of GolfScript, which seems to be due to some bugs/limitations of Ruby's Bignum. ### How it works A " Push 10. "; 28{ " Do the following 28 times: "; _* " Duplicate the integer on the stack and multiply it with its copy. "; }* " "; K* " Multiply the result by 20. ";  # CJam, ≈ 8.1 × 101,826,751 KK,{)*_*}/  Takes less than five minutes on my machine, so there's still room for improvement. This computes a20, defined as follows: • a0 = 20 • an = (n × an - 1)2 ### How it works KK, " Push 20 [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ]. "; { " For each integer in the array: "; )* " Increment it and compute the its product with the accumulator. "; _* " Multiply the result with itself. "; }/  • Haha, is that Kirby? :) Jun 13, 2014 at 15:28 • Could you describe what this is doing? Jun 13, 2014 at 17:59 • FYI, I ran some tests to check BigInteger performance - I calculated 100000! and converted to string. Results: java 6: 21 sec calculation, 44 sec toString; java 7: 14 sec calculation, 42 sec toString; java 8: 5 sec calculation, 1 sec toString! Jun 13, 2014 at 20:27 • @aditsu: Upgrading Java reduced the runtime from 5 minutes to 2 seconds! Jun 13, 2014 at 21:53 Wolfram Language ack(9!,9!)  Try it online! $$\text{ack}(9!,9!) = 2 \uparrow^{362878} 362883 - 3$$ Output is in Arrow Notation. • @KyleKanos Its different because the code/program isn't calling out to the web. Other Examples typescriptlang.org/Playground tryfsharp.org/Learn/getting-started Jun 15, 2014 at 1:52 • The Wolfram Language is available to use an Raspberry Pi and doesn't require web access. So isn't in violation of that rule. Jun 15, 2014 at 2:15 • I think it is very valid answer. Stupid reasoning for being on island and having no access to internet. 'No web' requirement is only to prevent printing output from a already available resource. All answers are valid as long as they 'run' a piece of code to calculate the output. Latest Visual Studio is coming that runs your code on the Azure cloud, so you want to restrict C#? Or you are ineligible if you have chromebook? Jun 19, 2014 at 17:08 • ack(99!,9) is much, much larger. Mar 13, 2015 at 2:21 • One of the other answers says that ack(4,2) is the largest he can calculate in an hour so I would be surprised if this did... Jul 7, 2015 at 12:32 # Any language with short enough constant names, 18 digits approx. 99/sin(PI)  I would post this as a PHP answer but sadly M_PI makes this just a little too long! But PHP yields 8.0839634798317E+17 for this. Basically, it abuses the lack of absolute precision in PI :p • Can't you do tan(PI/2)? Jun 13, 2014 at 15:56 • @user80551 Could do, but I just noticed that I could make use of that last remaining character in the limit to boost my result by 99 times. Jun 13, 2014 at 15:58 • Too long in Common Lisp: (/ 99(sin pi)) (14 characters). Error in TI-83: 99/sin(π (8 characters) causes division by zero. Works in LibreOffice Calc: =99/SIN(PI( (10 characters, not counting =) computes 808423047055000000. LibreOffice auto-inserts the last two )) in =99/SIN(PI()). Jun 13, 2014 at 20:12 • It's depending on the precision of the language. In PHP 14 decimal digits is a common value. Jun 14, 2014 at 9:42 • @kernigh It doesn't matter in this case, but would 99/sin(π be five bytes or eight? I know TI-BASIC stores a bunch of commands as single bytes; is sin( one of them? Jun 15, 2014 at 0:33 # Python 3, 9*2^(7*2^33) > 10^18,100,795,813 # 9*2^(2^35) > 10^10,343,311,894 Edit: My new answer is: 9<<(7<<33)  Old answer, for posterity: 9<<(1<<35)  Ten characters exactly. I am printing the number in hex, and You may exclude from the 10-character limit any code necessary to print anything. For example, in Python 2 which uses the print x syntax, you can use up to 16 characters for your program. Therefore, my actual code is: print(hex(9<<(7<<33)))  Proof that it runs in the specified time and generates a number of the specified size: time python bignum.py > bignumoutput.py real 10m6.606s user 1m19.183s sys 0m59.171s wc -c bignumoutput.py 15032385541 bignumoutput.py  My number > 10^(15032385538*log(16)) > 10^18100795813 3 less hex digits than the above wc printout because of the initial 0x9. Python 3 is necessary because in python 2, 7<<33 would be a long, and << doesn't take longs as inputs. I can't use 9<<(1<<36) instead because: Traceback (most recent call last): File "bignum.py", line 1, in <module> print(hex(9<<(1<<36))) MemoryError  Thus, this is the largest possible number of the form a<<(b<<cd) printable on my computer. In all likelihood, the fastest machine in the world has more memory than I do, so my alternate answer is: 9<<(9<<99)  9*2^(9*2^99) > 10^(1.7172038461*10^30) However, my current answer is the largest anyone has submitted, so it's probably good enough. Also, this is all assuming bit-shifting is allowable. It appears to be, from the other answers using it. • So far this looks to be the largest answer by far. It's a 10,000,000,000 digit number, after all. Jun 14, 2014 at 15:09 • @nneonneo : I believe my solution is larger :) – Zaid Jun 15, 2014 at 11:37 • Your alternate answer requires juuuuust less than 1 MiYiB of memory, and requires 100 bits of addressable memory (so it won't work until at least 128-bit Python). (Source: my similar answer) Feb 8, 2017 at 20:22 # HTML, 9999999999 9999999999  .. nailed it. • not a programming language, though. – cat May 7, 2016 at 13:18 • Use PHP, it's better! May 7, 2016 at 19:19 • @cat In this case, it's fine, as this is reminiscent of kolmogorov complexity challenges. Feb 7, 2017 at 1:36 • 9&Hat;9999 prints 9^9999. Just sayin :) – Jan Feb 8, 2017 at 20:06 • saddly PHP_INT_MAX is 11 Feb 12, 2018 at 20:56 # Haskell Without any tricks: main = print -- Necessary to print anything$9999*9999 -- 999890001


Arguably without calculating anything:

main = print
$floor$1/0 -- 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137216


main = print
$99/sin pi -- 8.083963479831708e17  • Third bullet says "Your program must calculate..." Jun 13, 2014 at 19:51 • floor(infinity) is a finite number? What the heck Haskell? Jun 14, 2014 at 15:23 • 1/0 != infinity, it's undefined. Jun 15, 2014 at 17:39 • Are you sure about that, @ckuhn203? In both GHC 7.6.3 and 7.8.2, I get isInfinite$ 1 / 0 -- True. As far as I can tell, IEEE 754 defines 1 / 0 as infinity. Jun 16, 2014 at 14:30
• Oh, you mean mathematically. I agree completely. But as far as programming with IEEE floating point (and Haskell in particular) is concerned, 1 / 0 == Infinity. Jun 16, 2014 at 18:06

## Powershell - 1.12947668480335E+42

99PB*9E9PB


Multiplies 99 Pebibytes times 9,000,000,000 Pebibytes.

• 98901 sq petabytes? Is that some sort of method to measure the surface bit density of (future high-capacity)hard-disks? Jun 14, 2014 at 13:33
• Oh, nice. Didn't know pebibytes were possible by now. I always thought it stopped at tebibytes.
– Joey
Jun 17, 2014 at 17:40
• @Joey Now if MS would only hurry up and add yobibytes, the answer could be even better. Jun 17, 2014 at 18:26
• I could add that to Pash if it helps ... ;-)
– Joey
Jun 17, 2014 at 21:45
• 1+"1"*309 outputs 1.1111e308 though I suppose this breaks the spirit, if not the word of the rule on printing characters. It's cast to a double for output. Jan 20, 2016 at 15:01

# J (((((((((9)!)!)!)!)!)!)!)!)

Yeah, that's a lot. 10^(10^(10^(10^(10^(10^(10^(10^6.269498812196425))))))) to be not very exact.

!!!!!!!!9x

• I did find a compiler, but after 20 minutes, !!9x hasn't printed anything to screen. I sincerely doubt that !!!!!!!!9x will ever be computed. Jun 13, 2014 at 15:47
• "If it takes longer than an hour to run on the fastest computer in the world, it's invalid." Not sure this would be valid since it doesn't run within an hour Jun 13, 2014 at 15:52
• It took 70 minutes, but !!9x finally printed to screen. I'm impressed that it actually computed the value, but it still completely fails bullet 5. Jun 13, 2014 at 17:04
• @Quincunx: Likely true, however the condition for a valid answer is that the program must succeed in output; this answer completely fails that criterion. Sadly, the upvoters have neglected all the comments pointing this out and still upvote it over the CJam & Golfscript answers that are insanely huge and compute in reasonable time. Jun 13, 2014 at 18:01
• Downvoted because it doesn't print out the answer. Jun 15, 2014 at 7:38

# K/Kona: 8.977649e261 1.774896e308

*/1.6+!170

• !170 creates a vector of numbers from 0 to 169
• 1.6+ adds one to each element of the vector & converts to reals (range is 1.6 to 170.6)
• */ multiplies each element of the array together

If Kona supported quad precision, I could do */9.+!999 and get around 1e2584. Sadly, it doesn't and I'm capped to double precision.

old method

*/9.*9+!99

• !99 creates a vector of numbers from 0 to 98
• 9+ adds 9 to each element of the vector (now ranges 9 to 107)
• 9.* multiplies each element by 9.0 (implicitly converting to reals, so 81.0 through 963.0)
• */ multiplies each element of the vector together

# Python - Varies, up to 13916486568675240 (so far)

Not entirely serious but I thought it would be kinda fun.

print id(len)*99


Out of all the things I tried, len was most consistently getting me large ids.

Yielded 13916486568675240 (17 digits) on my computer and 13842722750490216 (also 17 digits) on this site. I suppose it's possible for this to give you as low as 0, but it could also go higher.

• Great idea but unfortunately it doesn't calculate anything. Jun 13, 2014 at 14:54
• I do believe the *99 part invokes a calculation. Jun 13, 2014 at 14:55
• Oh yes, /me feels stupid now. Jun 13, 2014 at 14:59
• If you use something shorter - say id(id) or id(0j), you can multiply by 999 Jun 13, 2014 at 15:10
• Out of smaller named ones in docs.python.org/2/library/functions.html , vars consistently gives the highest value(but 4 chars) followed by sum. Use print(sorted([(id(x),x)for x in[id,len,max,min,str,int,ord,chr,sum,map,abs,all,any,bin,bool,eval,oct,vars,iter,list,set,repr,round,zip,type,pow,dict,dir,hex]])[::-1]) to check. Jun 13, 2014 at 15:49

# Golfscript, 1e+33,554,432

10{.*}25*


Computes 10 ^ (2 ^ 25), without using exponents, runs in 96 seconds:

$time echo "10{.*}25*" | ruby golfscript.rb > BIG10 real 1m36.733s user 1m28.101s sys 0m6.632s$ wc -c BIG10
33554434 BIG10
$head -c 80 BIG10 10000000000000000000000000000000000000000000000000000000000000000000000000000000$ tail -c 80 BIG10
0000000000000000000000000000000000000000000000000000000000000000000000000000000


It can compute up to 9 ^ (2 ^ 9999), if only given enough time, but incrementing the inner exponent by one makes it take ~triple the time, so the one hour limit will be reached pretty soon.

Explanation:

Using a previous version with the same idea:

8{.*}25*


Breaking it down:

8         # push 8 to the stack
{...}25*  # run the given block 25 times


The stack at the start of each block consists of one number, the current number. This starts off as 8. Then:

.         # duplicate the top of the stack, stack is now | 8 | 8 |
*         # multiply top two numbers, stack is now       | 64 |


So the stack, step by step, looks like this:

8
8 8
64
64 64
4096
4096 4096
16777216
16777216 16777216


... etc. Written in math notation the progression is:

n=0, 8                     = 8^1  = 8^(2^0)
n=1, 8*8                   = 8^2  = 8^(2^1)
n=2, (8^2)*(8^2) = (8^2)^2 = 8^4  = 8^(2^2)
n=3,               (8^4)^2 = 8^8  = 8^(2^3)
n=4,               (8^8)^2 = 8^16 = 8^(2^4)

• What's the deal with the two one's in front of the 2564 in your output? Jun 13, 2014 at 16:19
• @KyleKanos: That's not my output, it's the output of wc. I'll edit to make it clearer Jun 13, 2014 at 16:20
• you could use wc -c to make the output clearer Jun 13, 2014 at 16:29
• Nice! I had the same idea a few minutes ago, but it runs much slower with CJam (which is surprising, since it's faster than GolfScript in general). Jun 13, 2014 at 16:44
• Minor improvement: 10{.*}25 delivers 33,554,434 digits and finishes in 90 second on my machine. I don't know why, but 10{.*}26* prints nothing. Jun 13, 2014 at 19:31

# wxMaxima ~3x1049,948 (or 108,565,705,514 )

999*13511!


Output is

269146071053904674084357808139[49888 digits]000000000000000000000000000000


Not sure if it quite fits specs (particularly the output format one), but I can hit even larger:

bfloat(99999999!)


Output is

9.9046265792229937372808210723818b8565705513


That's roughly 108,565,705,514 which is significantly larger than most of the top answers and was computed in about 2 seconds. The bfloat function gives arbitrary precision.

Aww man, that's not a lot! 10 characters start after the dollar sign.

main=putStr.show$sum[1..99]  • Why not just print? Also, 9/0.000001 is greater than sum[1..99]. Jun 13, 2014 at 19:11 • At that rate, we might consider 9 999 999 999 to be a lower bound on results. – Keen Jun 13, 2014 at 20:22 • @TaylorFausak This answer is obviously not to be taken seriously! Jun 16, 2014 at 10:23 ## Mathematica, 2.174188391646043*10^20686623745 $MaxNumber


Ten characters exactly.

• Is it technically calculating anything, and is it outputting all the digits and not just scientific notation?
– user15259
Jun 13, 2014 at 20:12
• @Yimin: The output may be in any format (so you can print 999, 5e+100, etc.) Jun 13, 2014 at 23:14
• The value is not set at compile-time, but depends on the particular machine on which the command is run. I think it counts. Jun 13, 2014 at 23:25

# Casio fx-350 ES PLUS, approx. 9.999882753E99

Do calculators count?

At 70! the calculator throws error because apparently it has a number range limit -1E100 ~ 1E100

• I... don't think this counts as a programming language? Aug 2, 2019 at 18:49
• Well I guess there's another calculator answer so this is probably fine. Aug 2, 2019 at 18:52

# APL (Dyalog), 1.79769e308 (float64) or 9.99999e6144 (decimal128), 3 bytes

This is the minimum reduction of an empty list:

⌊/⍬


⌊ minimum

/ reduction

⍬ empty list

When reducing an empty list, APL will return the identity element of the function used (if known). For minimum reduction of a system without infinities (e.g. ISO APL, to which Dyalog APL adheres), the identity element for minimum is the largest representable number:

Try it online! (IEEE 754 64-bit floating-point)

Try it online! (IEEE 754-2008 128-bit decimal floating-point)

# Python shell, 649539 999890001

99999*9999

• 9999999999 is larger, isn't it? Jun 13, 2014 at 13:59
• @MadTux There is an ambiguous restriction to calculate the answer. Jun 13, 2014 at 13:59
• If this answer is correct, then mine 9**9**9**9 is correct either, as it's arithmetic operator (not built-in func). Jun 14, 2014 at 13:28
• @kenorb It's built in exponentiation that's not allowed. Jun 14, 2014 at 13:30

I'd rather post this as a comment above, but apparently I can't since I'm a noob.

Python:

9<<(2<<29)

I'd go with a larger bit shift, but Python seems to want the right operand of a shift to be a non-long integer. I think this gets closer to the theoretical max:

9<<(7<<27)

The only problem with these is that they might not satisfy rule 5.

# Binary Lambda Calculus, $$\ f_{\omega+2} (2)\$$, 9.75 bytes

This program outputs a number larger than Graham's Number while using 78 bits, which is 9.75 bytes, within the 10-byte budget given to me:

010101000001110011101000000101011000000101101101011010000110100000011100111010


If you prefer an ASCII display of the binary number, here it is:

T��mhh:


(Inspired, but not copied, by the entry mentioned here)

## How it works:

This Binary Lambda Calculus expression encodes the following expression below:

(\f x.f (f x))(\f n.n (\g m.m g m) f n)(\x.x x)(\f x.f (f x))


This Lambda Calculus expression uses Church Numerals. Church Numerals are generally considered to be the standard representation of natural numbers. What makes Church Numerals powerful is that they are defined using recursion:

[n] f m = f (f (f (...(f m)...))) with n f's.

What this means is that if we have a function $$\f\$$ and a natural number $$\n\$$, we can simply concatenate them into $$\n f\$$ to make a much faster function. You can read the article I linked above if you want to see how Church Numerals can be encoded in Lambda Calculus.

### Exponentiation

What is more, Church Numerals can even act on themselves! n m represents $$\m^n\$$ using exponentiation!

Example: $$\2^3\$$
(Here, we will apply that to the function f n, to show the true power of recursion)

• 3 2 f n
• 2 (2 (2 f)) n
• (2 (2 f)) ((2 (2 f)) n)
• (2 f) ((2 f) ((2 f) ((2 f) n)))
• f (f (f (f (f (f (f (f n)))))))
• = 8 f n

We can create a function that captures the true power of exponentiation!

\x.x x


When applied to a Church Numeral $$\n\$$, it returns $$\n^n\$$. Viola! Let's call our exponential combinator $$\E\$$, such that:

E = (\x.x x)


### Recursion

In order to get beyond exponentiation, we must recurse our $$\E\$$ combinator. Remember how popping a number before a function recurses it? Well, we can do this with the E combinator, provided that it is a unary function. Define the $$\R\$$ combinator as followed:

R = (\g. \m.m g m)


Here, how it works is that for a function $$\f\$$ applied to an number $$\n\$$, $$\Rfn\$$ reduces down to $$\nfn\$$. This is awesome, because Church numerals naturally recurse functions, meaning $$\nfn\$$ reduces down to $$\f (f (f ...(f n)...))\$$.

What if we let our function be our exponential combinator $$\E\$$? $$\REn\$$ grows tetrationally. But there is no reason to stop here. We can merge $$\R\$$ and $$\E\$$ into a single combinator, $$\(RE)\$$, and recurse that to have $$\R(RE)n\$$. This grows pentationally.

We can have $$\R(R(RE))n\$$, $$\R(R(R(RE)))n\$$, and so on. But notice how the $$\R\$$ combinator is being recursed over $$\E\$$. Well, this is where Church Numeral Recursion comes back into play.

### Super-Recursion

Define a new combinator, $$\S\$$, as the following:

S = (\f n.n R f n) = (\f n.n (\g m.m g m) f n)


Cool, now one thing that makes this powerful is that while the $$\R\$$ combinator recurses over a function $$\f\$$, the $$\S\$$ combinator repeatedly applies the $$\R\$$ combinator to a function $$\f\$$. Consider this:

$$SE3$$

The first thing that $$\S\$$ combinator is going to do is to reduce to $$\nR\$$ where n is the number after the $$\E\$$. So our reduction will look like this:

$$3RE3$$

The Church Numeral recursion applies on $$\R\$$ over $$\E\$$, thus nesting $$\R\$$ three times, thus giving us this:

$$R(R(RE))3$$

As we seen above, each $$\R\$$ increases the size of the number considerably, and now the $$\S\$$ combinator recurses over the $$\R\$$ combinator! The combinator (SE) grows at $$\f_{\omega}\$$ in the Fast Growing Hierarchy, about the limit of the Ackermann Function. We can take this a step forward.

• $$\R(SE)\$$ recurses over the (SE) combinator, growth rate similar to Graham's Number
• $$\R(R(SE))\$$ has $$\f_{\omega+2}\$$ growth in the fast growing hierarchy
• $$\S(SE)\$$ has $$\f_{\omega2}\$$ growth in the fast growing hierarchy
• $$\S(S(SE))\$$ has $$\f_{\omega3}\$$ growth in the fast growing hierarchy

Similar to how inserting a church numeral before $$\R\$$ can recurse the recursion function over $$\E\$$, inserting a church numeral before $$\S\$$ recurse the super-recursion function over $$\E\$$. For example, $$\2SE\$$ = $$\S(SE)\$$.

## The Number:

The number is $$\2SE2\$$ using Church Numerals and the combinators defined above. This translates to about $$\f_{\omega+2} (2)\$$ in the Fast Growing Hierarchy, which is greater than Graham's Number. Graham's Number is far greater than even $$\Ack(9!,9!)\$$ in Wolfram-Alpha. Expanding $$\2SE2\$$ will yield:

(\f x.f (f x))(\f n.n (\g m.m g m) f n)(\x.x x)(\f x.f (f x))


The lambda expression for $$\2\$$ is (\f x.f (f x)), as you can see it is a Church Numeral. By decoding this Lambda Calculus Expression in Binary Lambda Calculus, one could expect a 9.75-byte expression:

010101000001110011101000000101011000000101101101011010000110100000011100111010


We proved that we can beat Graham's Number in 10 bytes! Ridiculous?

• (\t. t t S E t) 3 -> 3 3 S E 3 -> 27 S E 3 this reaches $f_{\omega27}(3)$ using 79 bits: 0100010101011010000001010110000001011011010110100001101010000001110011100111010 Jun 1, 2021 at 1:33

## Befunge-93 (1,853,020,188,851,841)

Glad nobody has done Befunge yet (it's my niche), but dammit I can't find any clever trick to increase the number.

9:*:*:*:*.


So it's 9^16.

:*


Basically multiplies the value at the top of the stack with itself. So, value at the top of the stack goes:

9
81
6561
43046721
1853020188851841


and

.


Outputs the final value. I would be interested to see if anybody has any better ideas.

## At least Python 3.5.0 (64-bit), more than 10^242944768872896860

print("{:x}".format( 9<<(7<<60) ))


In an ideal world, this would be 9<<(1<<63)-1, but there aren't enough bytes for that. This number is so big that it requires almost 1 EiB of memory to hold it, which is a little bit more than I have on my computer. Luckily, you only need to use around 0.2% of the world's storage space as swap to hold it. The value in binary is 1001 followed by 8070450532247928832 zeros.

If Python comes out for 128-bit machines, the maximum would be 9<<(9<<99), which requires less than 1 MiYiB of memory. This is good, because you'd have enough addressable space left to store the Python interpreter and the operating system.

• "Only 0.2% of the world's storage space" Apr 13, 2019 at 20:51
• @BenjaminUrquhart If you think it's good, why not upvote? Apr 13, 2019 at 20:58
• There's your double upvote ;) Apr 13, 2019 at 20:58

# Matlab (1.7977e+308)

Matlab stores the value of the largest (double-precision) floating-point number in a variable called realmax. Invoking it in the command window (or at the command line) prints its value:

>> realmax

ans =

1.7977e+308

• Since the OP asked to return a calculated value, you should put realmax+1. I tried it for fun and surprise it returns exactly the same number than you have (then I laughed when I realized ... eps(realmax)=1.99584030953472e+292 ).
– Hoki
Jul 7, 2015 at 11:39

# Python, ca. 1.26e1388

9<<(9<<9L)


Gives:

126026689735396303510997749074166929355794746000200933374690887068497279540873057344588851620847941756785436041299246554387020554314993586209922882758661017328592694996553929727854519472712351667110666886882465827559219102188617052626543482184096111723688960246772278895906137468458526847698371976335253039032584064081316325315024075215490091797774136739726784527496550151562519394683964055278594282441271759517280448036277054137000457520739972045586784011500204742714066662771580606558510783929300569401828194357569630085253502717648498118383356859371345327180116960300442655802073660515692068448059163472438726337412639721611668963365329274524683795898803515844109273846119396045513151325096835254352967440214290024900894106148249792936857620252669314267990625341054382109413982209048217613474462366099211988610838771890047771108303025697073942786800963584597671865634957073868371020540520001351340594968828107972114104065730887195267530118107925564666923847891177478488560095588773415349153603883278280369727904581288187557648454461776700257309873313090202541988023337650601111667962042284633452143391122583377206859791047448706336804001357517229485133041918063698840034398827807588137953763403631303885997729562636716061913967514574759718572657335136386433456038688663246414030999145140712475929114601257259572549175515657577056590262761777844800736563321827756835035190363747258466304L

# Perl, non competing

I'm using this to highlight a little know corner of perl.

Perl can't really compete on this one because it doesn't have builtin bignums (of course you could load a bignum library).

But what everybody knows isn't completely true. One core function actually can handle big numbers.

The pack format w can actually convert any size natural number between base 10 and base 128. The base 128 integer is however represented as string bytes. The bitstring xxxxxxxyyyyyyyzzzzzzz become the bytes: 1xxxxxxx 1yyyyyyy 0zzzzzzz (every byte starts with 1 except the last one). And you can convert such a string to base 10 with unpack. So you can write code like:

unpack w,~A x 4**4 .A


which gives:

17440148077784539048602210552864286760481312243331966651657423831944908597692986131110771184688683631223604950868378426010091037391551287028966465246275171764867964902846884403624214574779667949236313638077978794791039372380746518407204456880869394123452212674801443116750853569815557532270825838757922217314748231826241930826238846175896997055564919425918463307658663171965135057749089077388054942032051553760309927468850847772989423963904144861205988704398838295854027686335454023567793114837657233481456867922127891951274737700618284015425


You can replace the 4**4 by larger values until you feel it takes too long or uses too much memory.

Unfortunately this is way too long for the limit of this challenge, and you can argue that the base 10 result is converted to a string before it becomes the result so the expression doesn't really produce a number. But internally perl really does the needed arithmetic to convert the input to base 10 which I always considered rather neat.

# TI-36 (not 84, 36), 10 bytes, approx. 9.999985426E99

Older calculators can be programmed to an extent as well ;)

69!58.4376

This is very close to the maximum range a TI calculator can display: -1E100<x<1E100

## ><>

2020 update:

'*:*l1=?n!

Try it online!

A nice, big number.

6607775919524790651439701166707789489378797865523309469653600804966653717124420234900643695716633983263105744751733811265946551350757473520290996592227365993351117075631863250858664418726460620430636874466736708735091515674858617262672061392356105274688381926671523379031815127376998794734801639561117309008230181917173237247958670364395979998445068443549603086925428413456037483510188036968643022754136876546302694036337733250775972540791054488317803988268522700511802405629821189614545680714572177873101991977461377780062066275613653646526353437038254323542049537486740164431723433218814788820554530926749282165106713414138827765731299184793201063834591836604608194080942136186867241173559749340134123556348756219648917627921044482452298279885527390296021299809895208344965720017693561708427752229404713795765501476321809083160697802384075712539404128882728723305116462257211512254983151160419880169748505483542215949682009001146040637299350914438311533945478015790682139849329365319957805121129755402607972548916020445921204515251014341335241310585757251648664383763145215969276240907124147926204015695626240000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

## 3147440830160257032480100000000 319626579315078487616775634918212890625

Edit:

Seems like I am allowed to exclude the characters needed for printing, the n in this case, so here is an updated version:

':*:*:*:*nÿ


'*:*:*:*n;


Here, ' activates stringmode, and pushes all the following characters to the stack, before wrapping and exiting stringmode. Then it does a multiply-and-copy chain, printing the number, and exits. Of interest here is the ascii value of n 110, and ; 59.

However, if we allow it to terminate with an error, we can abuse the fact that the official interpreter supports Unicode. The title of the question says bytes, but the text says characters, so the following program is just for the fun of it.

'*:*:*:*n🿿


Outputting 1867215243681462552708446358738678532523702556144100000000

Alternatively, to stick to bytes, ÿ at the end gives us 383233022803952503175039062500000000, and that is still nice.

(New "for fun" program ':*:*:*:*n🿿 prints 7587624076546380447593767884781979512738274729546264306618287972087303430335365121)

# ARM Thumb, multiword integer, ~1.157921e+77 ~4.973232e+86

Machine code:

2306 1fd9 000a b407 b407


Assembly

        .globl main
.thumb
.thumb_func
main:
push    {r4, lr}
// start number generation code
movs    r3, #6             // 2
subs    r1, r3, #7         // 4
movs    r2, r1             // 6
push    {r1, r2, r3}       // 8
push    {r1, r2, r3}       // 10
// end number generation code
// now printf everything
bl      printf
pop     {r1, r2, r3}
pop     {r1, r2, r3, r4, pc}
// print 32 bits at a time
.Lprintf_str:
.asciz "%#08x%08x%08x%08x%08x%08x%08x%08x%08x\n"


Try it online! (sorta)

Assembles a 288-bit big endian unsigned integer (with little endian words) with the high 96 bits in r1-r3 and the low 192 bits on the stack.

The number is, in hex, 0xffffffffffffffff00000006ffffffffffffffff00000006ffffffffffffffff00000006, or in base 10, 497323236409786642128422301523609912453495901056838330362914156057471888398396751347718.

# Explanation

You may be wondering why I chose 6 and 7. The reason is because of the limitations of narrow instructions.

movs Rd, #imm can only encode an 8-bit immediate from 0-255. No negatives allowed, which would make this almost too easy.

subs Rd, Rn, #imm can only encode a 3-bit immediate from 0-7. I can only subtract 0-255 if I use the same destination register, which isn't very helpful.

So therefore, since r1 will be more significant, we put 6 in r3, then subtract 7 to get -1, or 0xFFFFFFFF, in r1.

        movs    r3, #6             // 2
subs    r1, r3, #7         // 4


Now, time for things to get super dumb.

First, we duplicate 0xFFFFFFFF to r2 using movs.

        movs    r2, r1             // 6


Then, we (ab)use ARM's push instruction. ARM's push instruction (as well as its sibling stm) can push multiple registers at once to the stack, effectively doing a block copy.

We abuse this to copy r1, r2, and r3 to the stack twice, tripling the width of the integer.

You could say this is some form of exponentiation, but all I'm doing is pushing to the stack. Nothing suspicious here. 😇

        push    {r1, r2, r3}       // 8
push    {r1, r2, r3}       // 10


Now, it looks like this:

   r1: 0xFFFFFFFF    r2: 0xFFFFFFFF
r3: 0x00000006
sp+0: 0xFFFFFFFF  sp+4: 0xFFFFFFFF
sp+8: 0x00000006 sp+12: 0xFFFFFFFF
sp+16: 0xFFFFFFFF sp+20: 0x00000006


# ARM Thumb-2, softfloat, 1.797693e+308

Machine code:

f248 0310 041b 17da 43db


Assembly:

        .thumb
.globl main
.thumb_func
main:
push    {r4, lr}
// Begin number generation code
movw    r3, #0x8010     // 4
lsls    r3, r3, #16     // 6
asrs    r2, r3, #31     // 8
mvns    r3, r3          // 10
// End number generation code
bl      printf
pop     {r4, pc}

.align 4
.printf_str:
.asciz "%f\n"


Try it online! (sorta)

Creates the 64-bit constant 0x7fefffffffffffff, which is DBL_MAX, in r2-r3 (since the AAPCS aligns 64-bit integers to even registers)

Specifically, 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000

We do this by first putting ~(*(long long*)&DBL_MAX) >> 48 in r3, shifting left by 16, doing an arithmetic shift right into r2 to make it 0xFFFFFFFF, then do a one's complement to get r3 to 0x7fefffff.

# ARM Thumb-2, (non-competing), softfloat + printf merging, 2.148532e+319

Machine code:

f248 0110 0409 43ca 0013


Assembly:

        .thumb
.globl main
.thumb_func
main:
push    {r4, lr}
// Begin number generation code
movw    r1, #0x8010     // 4
lsls    r1, r1, #16     // 6
mvns    r2, r1          // 8
movs    r3, r2          // 10
// End number generation code
bl      printf
pop     {r4, pc}

// Combine 0x80100000u (2148532224) with the same double we had before.
.printf_str:
.asciz "%u%f\n"


Try it online! (sorta)

This is obviously cheating, as it is actually generating an unsigned integer and a double and printing them together, but decided to add it for the lulz. 😂

It basically does this:

uint32_t r1 = (~0x7fef) & 0xffff;
// 0x80100000
r1 <<= 16;
uint32_t r2 = ~r1;
uint32_t r3 = r2;
// 0x7fefffff7fefffff
uint64_t r2r3 = r2 | ((uint64_t)r3 << 32);
double d = *(double*)&r2r3;
printf("%u%f\n", r1, d);