To compute the $n$th term in this sequence, you really only need decent estimates on the fractional parts of $(n-1)e$ and $ne$ (following Gerry Myerson's solution) - you get 2 if and only if the fractional part of $(n-1)e$ lies in $[0.5,1)$ and the fractional part of $ne$ lies in $[0,0.5)$. To find the fractional parts, you typically need about $m$ large integer divisions, where $m$ is such that $m!$ is a bit larger than $n$. A modern computer can do this quite quickly: SAGE took about 1 second to find that the $10^{100000}$th term is 3, and about 55 seconds to find that the $10^{1000000}$th term is also 3.

**Edit:** I'm still quite confused about Kevin O'Bryant's comments to the effect that knowledge of $e$ affects the operation count. To direct the conversation, I'll include some SAGE code that computes which half of the unit interval contains the fractional part of $ne$. An output of 0 means the fractional part lies in the lower half, while an output of 1 means it lies in the upper half.

```
def fracpart(n):
ipart = n
fpart = 0
acc = 0
k = 1
while ipart != 0 or ceil(2*acc)-2*acc < 2/k:
(ipart,rem) = ipart.quo_rem(k)
fpart = RDF(rem/k + fpart/k)
acc = acc + fpart
if acc >= 1: acc = acc - 1
k = k + 1
return floor(2*acc)
```

The large integer divisions occur in the function `quo_rem`

, while the other divisions are small. This code will return the correct answer for all but less than one out of a billion of the reasonable inputs - the remaining cases (where floating point precision isn't good enough) can be dealt with by using high-precision reals, removing the letters "RDF" to switch to rationals, or using some modular arithmetic to work with remainders.

The code uses the fact that $e$ expands as a sum of reciprocals of factorials in an essential way, but there doesn't seem to be any point where it explicitly computes the number $e$ itself. I'm not sure if this quality exempts the program from the previous criticism.