Given a positive integer n, you must calculate the nth digit of \$e\$, where \$e\$ is Euler's number (2.71828...).

The format of the output can be a number or a string (e.g., 3 or '3')


# e = 2.71828...

nthDigit(3) => 8
nthDigit(1) => 7
nthDigit(4) => 2

Shortest code wins.

  • 8
    \$\begingroup\$ Language like "You cannot use any external libraries or constants" is not up to our standards of clarity on this site. The best way to fix this problem is to remove the restriction, since it doesn't do anything good for your challenge in the first place. \$\endgroup\$ – Ad Hoc Garf Hunter May 14 at 1:37
  • 5
    \$\begingroup\$ @applemonkey496 It doesn't solve the challenge anyway because a floating-point number doesn't have infinite precision (the output can't be right after 15 digits or so). \$\endgroup\$ – Bubbler May 14 at 3:42
  • 3
    \$\begingroup\$ Is there an upper bound on \$n\$ for this challenge? \$\endgroup\$ – Dingus May 14 at 5:27
  • 2
    \$\begingroup\$ Even with arbitrary precision, it's not straightforward to get the n-th digit, because it may have been rounded up. For example, e with 4-decimal precision would give you 2.7183, but actually the 4-th decimal is 2, not 3 \$\endgroup\$ – Luis Mendo May 14 at 10:14
  • 1
    \$\begingroup\$ @MitchellSpector It would probably work for 05AB1E for 1 byte but it's just pseudocode. \$\endgroup\$ – Wezl May 14 at 18:18

10 Answers 10


05AB1E, 4 bytes


Pretty convenient builtin ¯\_(ツ)_/¯

Try it online or verify the first ten digits or output the infinite list of digits.


žt    # Push the infinite list of decimal value of e (including leading 2)
  sè  # And 0-based index the input-integer into it
      # (after which the result is output implicitly)
| improve this answer | |

Python 2, 34 32 bytes

Solution provided by @l4m2
-2 bytes thanks to @xnor

lambda n:`(100**n+1)**100**n`[n]

Try it online!

Very, very slow.

Verification up to \$166\$ digits. The idea for this verification comes from @l4m2: calculates \$x^{100^n}\$ by calculating x=x**10 repeatedly (\$2n\$ times), each time truncating \$x\$ to a few left most digits (the TIO link uses \$500\$ digits). By changing the truncation to round down or up, we obtain the lower and upper bound for the result. If the lower and upper bound agree to \$n\$ leftmost digits, we know that the exact calculation will also result in those \$n\$ digits.

I have verified that this solution works up to \$n = 333\$, using MAX_DIGITS = 1000.


This solution uses the following well known approximation of \$e\$: $$ e = \lim_{x \to \infty} \left(1 + \frac{1}{x} \right)^{x}$$ Substituting \$x = 100^n\$, we have: $$ e = \lim_{n \to \infty} \left(1 + \frac{1}{100^n} \right)^{100^n} = \lim_{n \to \infty} \frac{\left(100^n + 1 \right)^{100^n}}{\left(100^n\right)^{100^n}}$$ Since the denominator is a power of \$10\$, we can ignore it entirely.

According to this analysis on Math SE, the worst case error of this approximation is: $$ \Delta < \frac{3}{x} = \frac{3}{100^n}$$ which means roughly that every time \$n\$ increases by \$1\$, we gains 2 digits of precision.

| improve this answer | |
  • 1
    \$\begingroup\$ Is yur code or my optimize wrong? \$\endgroup\$ – l4m2 May 14 at 3:48
  • \$\begingroup\$ @l4m2 My solution is wrong unfortunately :( At first I thought your optimization slightly lowered the result due to truncation, e.g ...90... becomes ...89..., but even if I round up after each division, the result is still wrong. Even though my solution's error goes down by a factor of 10 every time n increases, the error can still be large enough to push patterns like ...200... down to ...199.... \$\endgroup\$ – Surculose Sputum May 14 at 5:07
  • \$\begingroup\$ So can this be wrong? (though it's much slower it's same length) \$\endgroup\$ – l4m2 May 14 at 5:13
  • 1
    \$\begingroup\$ My link's for such purpose \$\endgroup\$ – l4m2 May 14 at 6:47
  • 1
    \$\begingroup\$ Python's exponentiation actually right-associates so you can cut those parens. \$\endgroup\$ – xnor May 14 at 12:13

dc, 66 bytes


Try it online!

Or print more than 800 digits before TIO times out after a minute.

I've verified these 800 digits against the published value at a NASA web page with 2 million digits of e.

(It may be possible to shorten the code a bit by keeping some of the variables on the stack and accessing them via stack manipulation instead of using dc's registers.)


I     # 10.
?     # Input value.
d     # Push on stack for later.
F+k   # Add 15 and make that the number of decimal places to calculate.
^     # 10 ^ input value, saved on stack for use at end.
1sF   # 1!, stored in F.
2sE   # 2 is starting value for e.
2sN   # for (N=2; ... )
[q]sR # Macro R will be used to end loop.
[     # Start loop L.
  1         # Push 1 for later.
  lNlF*dsF  # F = N! and push on stack.
  /d        # 1 / N!, duplicate on stack
  0=R       # If 1/N! == 0 (to the number of decimal places being computed), end loop.
  lE+sE     # Otherwise e += 1/N!
  lN1+sN    # N++
  lLx       # Go back to start of loop L
]dsLx  # End macro, save it in L, and execute it.
+      # Get rid of extra 0 on stack.
lE     # e, computed with sufficient accuracy 
*      # Multiply by 10^input value, which was saved on the stack early on.
0k1/   # Truncate to integer.
I%    # Mod by 10 to get desired digit.
p     # Print digit.
| improve this answer | |

Python 3, 146 105 bytes


Try it online! (thanks to @SurculoseSputum)

This only uses small integers to calculate digits of \$e\$. With a modification to use a lazy upper bound for N, it uses the algorithm described in

A. H. J. Sale. "The calculation of \$e\$ to many significant digits." The Computer Journal, Volume 11, Issue 2, August 1968, Pages 229–230, https://doi.org/10.1093/comjnl/11.2.229

Essentially, the idea is that \$e\$ can be written in "base-factorial" as \$1.11111\dots\$, where digit \$n\$ has place value \$1/n!\$. The algorithm repeatedly multiplies this number by 10 to extract digits one at a time. In fact, if one were to record each value of q in the outer for loop, the result would be the first n digits of \$e\$.

One complexity is that we need to know how many digits in base-factorial to calculate. In this version, \$n+3\$ is (more than) sufficient. A previous version of this answer used an estimate from Taylor's theorem, and it looked for a value of N such that \$N!\geq 10^{n}\$, doing so by calculating all factorials until it exceeds this power of ten.

| improve this answer | |
  • 1
    \$\begingroup\$ +1 for this spigot algorithm (these algorithms are nice -- they produce one digit at a time as they run). I did a version in dc based on an algorithm similar to this one; unfortunately it came out to be longer than the dc answer that i posted earlier. (I golfed it down to 101 bytes, which isn't even close to the 66 bytes in the answer I posted.) \$\endgroup\$ – Mitchell Spector May 15 at 21:16
  • \$\begingroup\$ 119 bytes by replacing the loops with exec "..loop.."*n, and changing from a function to a program. \$\endgroup\$ – Surculose Sputum May 16 at 4:34
  • \$\begingroup\$ If you accept a larger value of N (aka N=n+3), then this can be shorten to 95 bytes. \$\endgroup\$ – Surculose Sputum May 16 at 5:01
  • \$\begingroup\$ @SurculoseSputum Thanks! I modified it to be Python 3 compatible, which loses 10 bytes to your 95. \$\endgroup\$ – Kyle Miller 2 days ago

05AB1E, 8 bytes


Try it online!

Very, very slow.

| improve this answer | |

SageMath, 35 33 bytes

lambda n:str(N(e,digits=n+9))[-9]

Try it online!

Very, very fast!

| improve this answer | |
  • \$\begingroup\$ Fastest gun or fastest code? \$\endgroup\$ – Λ̸̸ May 14 at 11:40
  • 1
    \$\begingroup\$ @Λ̸̸ You've got to ask yourself one question: "Do I feel lucky?" Well, do ya, punk? :P \$\endgroup\$ – Noodle9 May 14 at 11:53
  • \$\begingroup\$ You're lucky because you answered the question just before the question is closed. \$\endgroup\$ – Λ̸̸ May 14 at 11:56
  • \$\begingroup\$ @Λ̸̸ Oh wow! I am the lucky one today! :D \$\endgroup\$ – Noodle9 May 14 at 11:58
  • 1
    \$\begingroup\$ @Λ̸̸ That's nothing; I can still answer questions after they're closed! \$\endgroup\$ – Neil May 14 at 12:21

Jelly, 14 bytes


Try it online!

A monadic link taking a single integer, plus a niladic helper link.



Link f:
    *(10, input) # 10 * input

Main Link:
    tail(head(str(*(Increment(f()), f())), input)) # str((f() + 1) * (f()))[:input][-1]
| improve this answer | |
  • \$\begingroup\$ Do you mean 2-indexing? Since the question requires the digits after the decimal point. \$\endgroup\$ – Λ̸̸ May 14 at 1:51
  • \$\begingroup\$ @Λ̸̸ Well, whatever it is, it's the same as the other answers \$\endgroup\$ – Lyxal May 14 at 1:58
  • \$\begingroup\$ Here's how to do the same thing in 8 bytes. \$\endgroup\$ – Jonathan Allan May 14 at 15:17

Charcoal, 30 bytes


Try it online! Link is to verbose version of code. Works by calculating the Maclaurin expansion of 100ⁿe to n+10 terms. Explanation:


Input n.


Start with a term of 100ⁿ.


Initialise the total to 0.


Repeat n+10 times.


Add the current term to the total.


Divide the term by the number of loop iterations.


Print the nth digit of the total.

| improve this answer | |

Wolfram Language (Mathematica), 21 bytes

Floor[E 10^#]~Mod~10&

Try it online!

| improve this answer | |

bc -l, 37 bytes


Try test cases online!

Input on stdin, output on stdout.

| improve this answer | |

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.