# Largest number in ten bytes of code

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/… – MadTux Jun 13 '14 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 – user80551 Jun 13 '14 at 13:37
• Does bit-shift count as an exponentiation operator since it is equivalent to * 2^x ? – Claudiu Jun 13 '14 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 – David Z Jun 13 '14 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. – Reinstate Monica Jul 7 '15 at 13:12

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 – Adam Speight Jun 15 '14 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. – Adam Speight Jun 15 '14 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? – microbian Jun 19 '14 at 17:08
• ack(99!,9) is much, much larger. – jimmy23013 Mar 13 '15 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... – Jerry Jeremiah Jul 7 '15 at 12:32

# 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 '14 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 – Claudiu Jun 13 '14 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? – Kyle Kanos Jun 14 '14 at 2:19
• Do you pronounce this "time times time"? :-) (hi Timwi!) – Pierre Arlaud Jun 16 '14 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. – Alpha Jun 17 '14 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. – user19057 Jun 13 '14 at 21:58
• ack(4,2)+2, I WIN – user18660 Jun 13 '14 at 22:07
• I think you won. – Anonymous Pi Jun 15 '14 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. – Szabolcs Jun 16 '14 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. – Szabolcs Jun 16 '14 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 – James_pic Jun 13 '14 at 15:05
• That's really just 9 * 2**9999999, so one could argue it uses exponentiation. – Dennis Jun 13 '14 at 15:29
• Wait, ***built-in*** exponentiation functions are not allowed so this might slip under the rules. +1 – user80551 Jun 13 '14 at 15:53
• Mathematical way of computing the length: floor(log10(9 * 2**9999999))+1 – Justin Jun 13 '14 at 18:09
• 9<<(9<<99) is a lot bigger, if it terminates. – Keith Randall Jun 14 '14 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? :) – aditsu quit because SE is EVIL Jun 13 '14 at 15:28 • Could you describe what this is doing? – Kyle Kanos Jun 13 '14 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! – aditsu quit because SE is EVIL Jun 13 '14 at 20:27 • @aditsu: Upgrading Java reduced the runtime from 5 minutes to 2 seconds! – Dennis Jun 13 '14 at 21:53 # 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)? – user80551 Jun 13 '14 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. – Niet the Dark Absol Jun 13 '14 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()). – kernigh Jun 13 '14 at 20:12 • It's depending on the precision of the language. In PHP 14 decimal digits is a common value. – kenorb Jun 14 '14 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? – wchargin Jun 15 '14 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. – nneonneo Jun 14 '14 at 15:09 • @nneonneo : I believe my solution is larger :) – Zaid Jun 15 '14 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) – wizzwizz4 Feb 8 '17 at 20:22 # 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..." – user80551 Jun 13 '14 at 19:51 • floor(infinity) is a finite number? What the heck Haskell? – nneonneo Jun 14 '14 at 15:23 • 1/0 != infinity, it's undefined. – RubberDuck Jun 15 '14 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. – Taylor Fausak Jun 16 '14 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. – Taylor Fausak Jun 16 '14 at 18:06

# HTML, 9999999999

9999999999


.. nailed it.

• not a programming language, though. – cat May 7 '16 at 13:18
• Use PHP, it's better! – CalculatorFeline May 7 '16 at 19:19
• @cat In this case, it's fine, as this is reminiscent of kolmogorov complexity challenges. – Addison Crump Feb 7 '17 at 1:36
• 9&Hat;9999 prints 9^9999. Just sayin :) – Jan Feb 8 '17 at 20:06
• saddly PHP_INT_MAX is 11 – ArtisticPhoenix Feb 12 '18 at 20:56

## 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? – user80551 Jun 14 '14 at 13:33
• Oh, nice. Didn't know pebibytes were possible by now. I always thought it stopped at tebibytes. – Joey Jun 17 '14 at 17:40
• @Joey Now if MS would only hurry up and add yobibytes, the answer could be even better. – Rynant Jun 17 '14 at 18:26
• I could add that to Pash if it helps ... ;-) – Joey Jun 17 '14 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. – tomkandy Jan 20 '16 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. – Kyle Kanos Jun 13 '14 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 – Claudiu Jun 13 '14 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. – Kyle Kanos Jun 13 '14 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. – Kyle Kanos Jun 13 '14 at 18:01
• Downvoted because it doesn't print out the answer. – isaacg Jun 15 '14 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. – user80551 Jun 13 '14 at 14:54
• I do believe the *99 part invokes a calculation. – commando Jun 13 '14 at 14:55
• Oh yes, /me feels stupid now. – user80551 Jun 13 '14 at 14:59
• If you use something shorter - say id(id) or id(0j), you can multiply by 999 – gnibbler Jun 13 '14 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. – user80551 Jun 13 '14 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? – Kyle Kanos Jun 13 '14 at 16:19
• @KyleKanos: That's not my output, it's the output of wc. I'll edit to make it clearer – Claudiu Jun 13 '14 at 16:20
• you could use wc -c to make the output clearer – daniero Jun 13 '14 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). – Dennis Jun 13 '14 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. – Dennis Jun 13 '14 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]. – Taylor Fausak Jun 13 '14 at 19:11 • At that rate, we might consider 9 999 999 999 to be a lower bound on results. – Keen Jun 13 '14 at 20:22 • @TaylorFausak This answer is obviously not to be taken seriously! – Flonk Jun 16 '14 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 '14 at 20:12
• @Yimin: The output may be in any format (so you can print 999, 5e+100, etc.) – edc65 Jun 13 '14 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. – Michael Stern Jun 13 '14 at 23:25

# Python shell, 649539 999890001

99999*9999

• 9999999999 is larger, isn't it? – MadTux Jun 13 '14 at 13:59
• @MadTux There is an ambiguous restriction to calculate the answer. – user80551 Jun 13 '14 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). – kenorb Jun 14 '14 at 13:28
• @kenorb It's built in exponentiation that's not allowed. – user80551 Jun 14 '14 at 13:30

# 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? – Simply Beautiful Art Aug 2 '19 at 18:49
• Well I guess there's another calculator answer so this is probably fine. – Simply Beautiful Art Aug 2 '19 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)

## 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.

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.

## 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" – Benjamin Urquhart Apr 13 '19 at 20:51
• @BenjaminUrquhart If you think it's good, why not upvote? – wizzwizz4 Apr 13 '19 at 20:58
• There's your double upvote ;) – Benjamin Urquhart Apr 13 '19 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 '15 at 11:39

# Python, ca. 1.26e1388

9<<(9<<9L)


Gives:

126026689735396303510997749074166929355794746000200933374690887068497279540873057344588851620847941756785436041299246554387020554314993586209922882758661017328592694996553929727854519472712351667110666886882465827559219102188617052626543482184096111723688960246772278895906137468458526847698371976335253039032584064081316325315024075215490091797774136739726784527496550151562519394683964055278594282441271759517280448036277054137000457520739972045586784011500204742714066662771580606558510783929300569401828194357569630085253502717648498118383356859371345327180116960300442655802073660515692068448059163472438726337412639721611668963365329274524683795898803515844109273846119396045513151325096835254352967440214290024900894106148249792936857620252669314267990625341054382109413982209048217613474462366099211988610838771890047771108303025697073942786800963584597671865634957073868371020540520001351340594968828107972114104065730887195267530118107925564666923847891177478488560095588773415349153603883278280369727904581288187557648454461776700257309873313090202541988023337650601111667962042284633452143391122583377206859791047448706336804001357517229485133041918063698840034398827807588137953763403631303885997729562636716061913967514574759718572657335136386433456038688663246414030999145140712475929114601257259572549175515657577056590262761777844800736563321827756835035190363747258466304L

# 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);


## Scala, 263-1

Poor, poor Scala. Takes at least 8 characters to get a BigInt value, which doesn't leave enough room to actually make it big.

But with only 7 characters of (counted) code, we can print the largest possible positive Long:

print(-1L>>>1)


# Brainf**k 256 - 2147483647

>+[<+>+]<.


If you ignore the fact that most compilers & interpreters output data as it's ascii equivalent (be leanient, it is what it is ;) ), this will return the maximum value of the interpreter/compiler's datatype.

On some systems this is just 256, although on some (mine for example), this is the max value of a 32 bit integer, ie 2 147 483 647.

Edit:

-.


Will print the same thing in many fewer characters

• That second answer will print -1 on interpreters that use signed values for the tape – Benjamin Urquhart Apr 13 '19 at 23:46