__int128

__int128 is a 128-bit integer type that GCC and Clang offer as a compiler extension on 64-bit targets — no header, no library, just __int128 (signed) and unsigned __int128. It is the C port's answer to a problem Python never has: a native long long tops out near $9.2 \times 10^{18}$, and a great many of these problems produce an intermediate — or a final answer — that steps just past that line. __int128 roughly doubles the digit budget to about $1.7 \times 10^{38}$ signed (and $3.4 \times 10^{38}$ unsigned), which is exactly enough for the values below, at close to the speed of ordinary machine arithmetic. It recurs because the Python solution's unbounded int hides an overflow that the C translation must actively defend against, and 128 bits is usually the cheapest defence.

The idea

There are two distinct jobs __int128 does, and it helps to keep them apart.

A transient widening for one multiply. Modular exponentiation, Miller–Rabin primality, and Pollard's rho all reduce to one hot step: a * b % m where a, b, and m all fit in 64 bits but the product a * b does not. Reduced operands near a modulus of $10^{10}$ multiply to nearly $10^{20}$, over the 64-bit ceiling, so the product is computed in 128 bits and immediately reduced back down. Problem 48's hand-written mod_pow is the canonical shape — the wide value never outlives the expression:

result = (__int128)result * base % mod;   /* product held at 128 bits, then reduced to 64 */
base   = (__int128)base * base % mod;

One cast is enough: promoting either operand promotes the whole multiply. This is the most common appearance by far — Problem 97 casts to __int128 for the same near-$10^{20}$ product in its modular exponentiation, and the private number-theory problems that lean on Miller–Rabin or modular arithmetic carry the identical (__int128)x * x % n idiom inside their inner loop. Problem 271 shows the idiom's signed companion. Its modulus is about $1.3 \times 10^{16}$, so the residues fit in unsigned long long, but the extended Euclidean inverse it needs for the Chinese remainder step tracks Bézout coefficients that go negative. The port runs that loop in signed __int128, so a value as large as an unsigned 64-bit modulus and its negative are both in range. Only at the end does it fold the result back into $[0, m)$.

A wider place to keep the answer. The other job is not transient at all: the result itself is too big for 64 bits but fits in ~38 decimal digits, so the whole accumulator is widened. Problem 31's dynamic-programming table is declared __int128 because a large coin target pushes the count past 23 digits; the DP runs entirely in 128-bit cells and only the final answer is narrowed. A defensive variant of this is to keep a continued-fraction convergent or a running product in __int128 throughout — deliberately, because the wide arithmetic is so cheap here — and narrow to long long only at the return.

The printing gap. One wrinkle follows from being an extension rather than a standard type: the printf family cannot format a __int128, and there is no INT128_MAX. When the answer is held at 128 bits you convert it to a decimal string by hand — repeatedly take the value modulo 10 and divide, writing digits right-to-left into a buffer. Problem 31 carries exactly such an int128_to_str helper for its final DP cell. Problems 271, 473, 951 and 963 print their 128-bit answers the same way. A signed value needs one more step. Problem 935's Möbius sum can be negative, so its port writes the sign, then formats the magnitude as unsigned. The helper is short enough to carry in every port that needs it:

static void print_u128(unsigned __int128 v) {
    char buf[40], *p = buf + sizeof buf;
    *--p = '\0';
    do { *--p = (char)('0' + (int)(v % 10)); v /= 10; } while (v);
    fputs(p, stdout);
}

Patterns from the later problems

The later problems use the same two jobs, but they show several refinements worth knowing.

Widen the accumulator, not the elements. Often every individual value fits comfortably in 64 bits and only the running total crosses the line. In Problem 882 each number's game value, scaled to fixed point, is a long long, but the scaled sum over $10^6$ numbers passes $2^{63}$. Problem 963's tallies all fit in 64 bits, but the sum of their squares reaches about $4 \times 10^{20}$. Problem 272's total and Problem 943's subtree counts and sums behave the same way. So does Problem 297: its Fibonacci terms are long long, but the table of Zeckendorf block sums (the total term count below each Fibonacci number) passes $2^{64}$, so only that table is unsigned __int128. Problem 271 adds up every cube root of unity modulo its $1.3 \times 10^{16}$ modulus. Each root is a 64-bit residue, but enough of them are summed that the total needs 128 bits. Problem 473's depth-first search over phigital palindromes builds each candidate's integer part with exact long long terms, and only the running integer part and the grand total are __int128. Problem 531 is the plainest case. It sums a generalised CRT solution over every pair in a window of about $10^6$-sized moduli. Each solution is below $\operatorname{lcm}(n, m) \approx 10^{12}$, so it fits in 64 bits, but there are millions of pairs, so the total passes $2^{63}$. Only the total is unsigned __int128. Widening only the accumulator keeps the tables at 64 bits, which halves their memory and keeps the inner loops at native speed.

The same split works inside a single memo table. Problem 351 computes the totient summatory function $\Phi(n) \approx 3n^2/\pi^2$ over the quotients $\lfloor n/k \rfloor$. It sieves $\Phi$ at every value up to about $n^{2/3}$ and memoises the large quotients $n/k$ above that. $\Phi$ passes $2^{63}$ only past $n \approx 5.5 \times 10^9$, so the sieved prefix, which is the big array, stays long long. Only the few large-quotient entries, about $n^{1/3}$ of them, are __int128.

Reduce lazily: sum the products first, take the modulus once. A wide accumulator also pays off when the answer is wanted modulo $M$. The usual habit reduces after every multiply-add, so the inner loop runs a % on every step. Problem 866's recurrence is a convolution of the form $E(n) = (2n-1)\sum_j E(j)\,E(n-1-j)$, with every stored term already reduced below a modulus near $10^9$. Each product is then below $2^{60}$. An unsigned __int128 accumulator can absorb about $2^{68}$ of them before it could wrap, far more than the $n/2$ terms in one row. So the inner loop only multiplies and adds, and the row is reduced once at the end. The bound to check is the number of terms times the largest product. The port also uses the symmetry $E(j)E(n-1-j) = E(n-1-j)E(j)$ to sum half the row and double it.

Pick the width per modulus, not per program. One computation often works modulo two different sizes, and only the larger one needs 128 bits. Problem 457 finds the least root of $n^2 - 3n - 1$ modulo $p^2$ for primes up to about $10^7$. It takes a square root of 13 modulo $p$ by Tonelli–Shanks, then Hensel-lifts it to $p^2 \approx 10^{14}$. Everything modulo $p$ stays in plain 64-bit arithmetic, because $p < 2^{32}$ makes every product fit; the port's pow_mod says so in its comment. The Hensel correction is also computed modulo $p$ and only then multiplied by $p$, so it lands in the right residue class modulo $p^2$ without a wide multiply. Only the last step, halving $3 \pm r$ modulo $p^2$, multiplies two residues near $10^{14}$ and needs the (u128) cast. The general habit: find the largest modulus each step actually uses, and widen only those steps.

Widen one squared expression to get an exact floor. An exact floor of an irrational quantity is computed by squaring: $\lfloor x/\sqrt m \rfloor = \operatorname{isqrt}(\lfloor x^2/m \rfloor)$. The square is what overflows. Problem 950 runs to $N = 10^{18}$, so its squared terms reach about $10^{36}$: far past 64 bits, but inside the unsigned 128-bit range of $3.4 \times 10^{38}$. Its floors and run sums use unsigned __int128, and the integer square root starts from a sqrtl estimate and is corrected by exact multiplication. Problem 932 widens a discriminant $(m+1)^2 - 4\,\ell m$ the same way as $m$ approaches $10^{15}$. Problem 255 widens only the single multiply by $2 \times 10^{10}$ in its exact rounding step. Problem 1000 widens a product of three values near $10^9$, which overflows 64 bits even though each factor is small.

A wider type doesn't rescue an overflowing formula. In Problem 951, $\binom{2n}{n}$ fits in __int128 up to $n = 65$. The usual multiplicative formula still overflows in its intermediate products well before that. So the C port builds the coefficient from a row of Pascal's triangle, using only additions, and no intermediate ever exceeds the result. The bound you have to prove is on every intermediate, not just the answer. Problem 936 keeps the multiplicative formula and proves the bound instead. Its multiset coefficient $\left(\!\binom{k}{c}\!\right)$ is built as r = r * (k + i) / (i + 1), which is exact at every step, and the largest intermediate is one partial result times one more factor. Its forest counts stay below $2^{128}$ up to $N = 70$ only because that product does. Problem 632 shows the case where the wide type does help with intermediates. It counts numbers by how many square prime factors they have, using an alternating inclusion–exclusion sum $\sum_j (-1)^{j-k}\binom{j}{k} A_j$. Each count fits in 64 bits, but the partial sums do not: a term $\binom{j}{k} A_j$ can reach about $2^8 \cdot 10^{16}$ before the next term of opposite sign cancels most of it. So the accumulator is signed __int128, and the residue is taken only after the sum is complete. In an alternating sum, the size of the largest term is what needs the wide type, not the size of the result. Problem 839 meets the same cancellation as a difference of two sums. It counts single-bean moves through a potential function: the count equals $\sum i\,f_i - \sum i\,a_i$, the weighted moment of the final arrangement minus that of the start. Each moment reaches about $10^{21}$, but they differ by about $10^{17}$. Both are accumulated in __int128, and only their difference is narrowed.

Widen the coefficients of a small algebra. The same cancellation can happen inside a structured value instead of a single sum. Problem 967 counts numbers by a sum of prime factors modulo 3, and does the bookkeeping in the group ring $\mathbb{Z}[C_3]$: each element is a triple of integer coefficients, multiplied by a length-3 cyclic convolution, and the answer is the $x^0$ coefficient (a roots-of-unity filter done exactly, with no complex numbers). The weights are products $(x-1)^i (x^2-1)^j$, whose coefficients have mixed signs and grow like $2^{i+j}$. Multiplied by counts near $N$, they pass 64 bits, even though most of that size cancels in the final coefficient. So the C port makes the ring element itself an array of three signed __int128 values. It keeps every coefficient exact through the expansion and narrows only the one coefficient it reports. When a value is a small vector or polynomial, apply the width to every component, since you cannot easily prove which one stays small.

Widen the test, not the value. Sometimes the value you keep always fits in 64 bits, and only the candidate that a loop tests can overflow. Problem 615 enumerates products of primes below a limit with a depth-first search, and it prunes a branch as soon as parent * p > limit. Near the limit that product can pass $2^{64}$. It would then wrap to a small number and pass the test, and the search would continue down a branch that should have been cut. The port forms the candidate in unsigned __int128, compares it with the limit, and narrows it to 64 bits only once it has passed. Problem 659 needs the same care in a polynomial sieve over $4k^2 + 1$. It Hensel-lifts each root from $p^e$ to $p^{e+1}$, and the loop stops when the lifted root passes $N$. The prime power $q = p^e$ and the lifted root $k + qs$ can both exceed 64 bits on the last step, which is exactly the step that must fail the test. So $k$, $q$ and the stride variable are __int128. A value that is about to be rejected still has to be represented correctly, or the rejection test gives the wrong result.

Search over residues; build the wide value once. Problem 303 needs, for each $n$ up to $10^4$, the least multiple of $n$ written only with the digits 0, 1 and 2. Some of those multiples have 20 digits or more, past $2^{63}$. The port never searches over the multiples themselves. Its breadth-first search runs over residues modulo $n$, appending one digit at a time, so every state is a small int and the visited table has only $n$ entries. Only when residue 0 is reached does it walk the parent chain back and assemble the digits into an unsigned __int128. It then divides by $n$ at once, because the problem wants $f(n)/n$, and that quotient fits in long long. The wide value exists for one assembly and one division. Keep the search state in the small modulus, and let the wide type appear only where the actual number has to be written down.

Clear the denominator at 128 bits, divide once, and guard the input. A closed form with a small rational denominator is exact only when it is evaluated as one integer numerator followed by one exact division. The numerator is larger than the quotient by that denominator, so it can overflow even when the answer fits easily. Problem 276 sums a rounded-quadratic sequence as $\bigl(k(k+1)(2k+1)/6 + c\bigr)/12$. The cube-sized product is formed in __int128 before either division, and the quotient tables of its Möbius sieve are kept at 128 bits too. Problem 957 goes further. Its answer is an O(1) formula in powers of $2^n$ and $4^n$, signed (some terms alternate with $(-1)^n$ and $(-2)^n$), and scaled by 864 so every coefficient is an integer. The scaled numerator grows like $11 \cdot 16^n$, so the bound depends on the input. The port therefore does not just assume it fits: it rejects any $n$ outside the range where that numerator provably stays below $2^{127}$, and fails with an error instead of wrapping. When the width needed depends on the input, check the input at run time, because a proof made for one size does not cover the rest. Problem 359 is the simpler case of the same rule. Its room-number formula needs halved squares such as $\lfloor f^2/2 \rfloor$ and $r(r+1)/2$, and $r^2$ reaches about $10^{27}$. Every term is evaluated in __int128, the terms are summed over the divisors of the input, and the modulus is applied once, at the very end. Problem 987 clears a denominator of $m!$. Its DP over card ranks counts straights as if they were labelled, and the labels are removed with factors like $1/(c-k)!$. To keep every weight an integer, the port multiplies in a binomial at each step instead. The product telescopes to $m!$ times the true weight, so it divides the grand total by $m!$ once at the end. The weights also carry the signs of an inclusion–exclusion over flushes. The answer itself, about $1.1 \times 10^{19}$, lies between $2^{63}$ and $2^{64}$: unsigned long long could hold it but not the negative weights, and signed long long cannot hold it at all. Signed __int128 is the narrowest type that does both.

The same rule still works when the answer is wanted modulo $M$, where an exact division seems impossible. Problem 875 needs $\sum_{k \le n} k^7 \bmod M$. The Faulhaber polynomial for that sum has denominator 24. Multiplying by the inverse of 24 modulo $M$ would work here, but only because $M$ is coprime to 6, and the port does not depend on that. It evaluates 24 times the sum modulo $24M$. The exact integer is a multiple of 24, so its residue modulo $24M$ is also a multiple of 24, and dividing the residue by 24 gives the sum modulo $M$ exactly. The cost is a modulus 24 times larger: about $2.4 \times 10^{10}$ here, whose products reach $10^{21}$, so the whole evaluation runs in __int128. In general, to divide by $d$ modulo $M$, compute modulo $dM$ and divide the residue, and budget the extra $\log_2 d$ bits on each factor. Problem 731 meets the denominator from the other side. It reads digits of a sum of fractions $r_i/3^i$, and the carry into the integer part is found by putting every term over the common denominator $3^K$. The numerator is below $K \cdot 3^K$, which no longer fits in 64 bits. It does fit in 128, so a single exact division gives the carry.

If the exact value fits, don't start modular arithmetic until the end. Problem 875's trick is needed because its exact sum is too large. When the exact value fits in 128 bits, the simpler route is to skip the modular inverse entirely: compute the exact integer, divide it exactly, and reduce once. Problems 521 and 539 both need a triangular number $v(v+1)/2$ modulo $M$, with $v$ up to about $10^{13}$ and $5 \times 10^{17}$ respectively. The product $v(v+1)$ is formed in __int128, halved exactly, and only then reduced, so the halving needs no inverse of 2. Problem 612 counts unordered pairs as $(T^2 - D - T)/2$, where $T$ is the count of numbers and $D$ the number of ordered pairs that share no digit, found with a sum-over-subsets transform. $T$ is below $2^{60}$, so $T^2$ and $D$ fit in unsigned __int128. The subtraction is exact, and the halving and the final modulus are ordinary operations. Had the port reduced $T^2$ and $D$ first, it would have needed an inverse of 2, and the subtraction could have gone below zero. Signed versions need one extra step. Problem 539's recurrence subtracts a term, and C's % keeps the sign of the dividend, so the port adds $M$ back when the remainder is negative before narrowing.

When the input itself is wide, parse it yourself. Sometimes the number that does not fit in 64 bits is the argument. Problem 641 asks about $n = 10^{36}$ dice, which is far beyond strtoull. Nothing in the standard library parses a decimal string into a 128-bit value, so the port reads the digits into an unsigned __int128 with its own short loop, v = v * 10 + digit. It then takes an exact 128-bit integer square root right away, which gives $\lfloor\sqrt n\rfloor \approx 10^{18}$. From that point the rest of the algorithm runs in ordinary 64-bit arithmetic. The wide type is a doorway, not the working space. Problem 698 parses its index into unsigned __int128 the same way, and it also lets the type's width decide how far the search may go. It finds the $n$-th "123 number" by counting completions: each digit is chosen greedily by subtracting how many valid numbers each choice leaves. Those counts grow like $3^L$ with the length $L$, so the port caps the length at 80, because $3^{80} < 2^{128}$. Every count it can meet then fits by construction. Choose the bound from the type, and make it a compile-time constant. Problem 551 shows both habits together. Its digit-sum sequence is walked in memoised jumps over blocks of low digits, and for the larger cases the values reach about $10^{22}$. So the port parses its index into unsigned __int128 with the same loop, and sizes its table of powers of ten to 10^0 … 10^38, the largest power of ten the type can hold. It also uses a 128-bit value as a hash key, which no ready-made hash function accepts. The port folds the high 64 bits into the low 64 before the usual multiplicative mix, so both halves of the key affect the slot.

Factor a wide number through its narrow factors. Problem 955 walks from one triangular number to the next. Each step needs the divisors of $x(x+1)$, and that product reaches about $10^{25}$. A Pollard's rho on a 128-bit modulus would need a $128 \times 128$-bit multiply, which __int128 cannot hold. But $x$ and $x+1$ are each below $2^{64}$, and they are coprime. So the port factors them separately with the ordinary 64-bit Miller–Rabin and rho, using (u128)a * b % m inside, and merges the two prime lists. The 128-bit type appears only where the wide value is really needed: the cofactor $x(x+1)/p$, and the pruning test (u128)d * p >= x that stops divisor generation. When a wide number is a product of known factors, keep it as those factors for as long as possible.

Exact counts, floating weights. Some computations mix an exact count with an irrational factor. Problem 930 computes an expected hitting time as a sum over group characters of $m/(m - \sum_i \cos(2\pi k_i/n))$. Characters with the same multiset of cosines contribute the same term, so the port counts them by class and adds count × term. There are up to $n^m$ characters, and $16^{16} = 2^{64}$ already overflows 64 bits on the larger benchmark. A double would hold that magnitude, but it stops representing every integer above $2^{53}$, and the convolution that builds the counts adds them repeatedly. So the counts stay exact in unsigned __int128 through the whole convolution. Each one is converted to long double just once, at the leaf where it multiplies the cosine term. Keep the combinatorial part exact, and round only where it meets the part that was never exact.

Size the type for the largest case you run. A port is usually tested past the official input, and that larger case can set the width. Problem 510's answer for $n = 10^9$ fits in 64 bits, but its $n = 10^{14}$ benchmark reaches about $3 \times 10^{27}$, so its accumulator and its triangular numbers are unsigned __int128. Problem 935's pair count grows like $k^2/4$, which passes 64 bits only for the $N = 10^{10}$ extra case. Problem 936's tree counts grow exponentially in $N$, and the bound was checked up to the $N = 70$ benchmark. Do the estimate for every input you will run. If the port still has a limit, write it down in the code, as Problem 957 does.

Unsigned wrap-around can be exact. Unsigned arithmetic in C is arithmetic modulo $2^{128}$, which is a ring. A computation built only from addition, subtraction and multiplication therefore ends on the correct residue, even if intermediates wrap. If the true answer is known to lie in $[0, 2^{128})$, that residue is the answer. Problem 996's C port relies on this for its unreduced statement examples. It lets the arithmetic wrap modulo $2^{128}$, which is harmless because the true answers are positive and far smaller. The argument fails the moment a division, a comparison or a floor touches a wrapped intermediate, so use it only for pure ring arithmetic.

How to reason about it

Reach for __int128 in the C port the moment you can show a product or a sum crosses $9.2 \times 10^{18}$ but stays under ~38 digits — and prove that bound with a back-of-envelope estimate, not a guess. For the a * b % m case the reasoning is standard: two operands each below $m$ give a product below $m^2$, so any modulus under $2^{63.5}$ (about $1.3 \times 10^{19}$, which covers every $10^{10}$-scale modulus here) is safe in a 128-bit product. Use unsigned __int128 when you need the top bit — a genuine full-width $64 \times 64 \to 128$ product, as in a manual bignum multiply — since the unsigned range reaches $3.4 \times 10^{38}$.

The trade-offs are worth stating plainly:

  • It is not portable to every compiler. __int128 is a GCC/Clang extension present only on 64-bit targets; MSVC has no equivalent. For this project, built with GCC, that is a non-issue, but it is the reason the type never appears in portable library code.
  • There is no I/O and no <limits.h> constant. Budget for the hand-rolled decimal conversion whenever a 128-bit value has to be printed, and hard-code the $1.7 \times 10^{38}$ ceiling if you need to bound-check against it.
  • It is a hard ceiling, not arbitrary precision. 128 bits buys ~38 digits and no more. When an intermediate can exceed that — a product of many large factors, a modulus already near $2^{64}$ whose square overflows even 128 bits — the type silently wraps, and the right move is to switch the whole computation to a big-integer library. Several private solutions do exactly this: they use the native __int128 fast path while operands stay below $2^{64}$ and defer to GMP's mpz_t above it. If you stay at 128 bits, make the ceiling loud rather than silent, as Problem 957's input check does: an error on an out-of-range input is far better than a plausible-looking wrong number.

The through-line for the Python author is that none of this machinery exists in the reference solution — Python's int is unbounded, so the overflow is invisible until you translate. Treating __int128 as the default first step in C, and reaching past it to a big-integer library only when 38 digits genuinely will not hold, keeps the port both correct and fast.

Problems96 / 96

  • ● 0031 — Coin Sums
  • ● 0048 — Self Powers
  • ● 0066 — Diophantine Equation
  • ● 0080 — Square Root Digital Expansion
  • ● 0097 — Large Non-Mersenne Prime
  • ● 0101 — Optimum Polynomial
  • ● 0111 — Primes with Runs
  • ● 0121 — Disc Game Prize Fund
  • ● 0130 — Composites with Prime Repunit Property
  • ● 0131 — Prime Cube Partnership
  • ● 0133 — Repunit Nonfactors
  • ● 0137 — Fibonacci Golden Nuggets
  • ● 0140 — Modified Fibonacci Golden Nuggets
  • ● 0141 — Square Progressive Numbers
  • ● 0146 — Investigating a Prime Pattern
  • ● 0180 — Golden Triplets
  • ● 0184 — Triangles Containing the Origin
  • ● 0188 — Hyperexponentiation
  • ● 0200 — Prime-proof Squbes
  • ● 0208 — Robot Walks
  • ● 0209 — Circular Logic
  • ● 0216 — The Primality of $2n^2 - 1$
  • ● 0217 — Balanced Numbers
  • ● 0221 — Alexandrian Integers
  • ● 0233 — Lattice Points on a Circle
  • ● 0234 — Semidivisible Numbers
  • ● 0236 — Luxury Hampers
  • ● 0241 — Perfection Quotients
  • ● 0248 — Euler's Totient Function Equals 13!
  • ● 0250 — $250250$
  • ● 0255 — Rounded Square Roots
  • ● 0259 — Reachable Numbers
  • ● 0271 — Modular Cubes, Part 1
  • ● 0272 — Modular Cubes, Part 2
  • ● 0276 — Primitive Triangles
  • ● 0277 — A Modified Collatz Sequence
  • ● 0288 — An Enormous Factorial
  • ● 0290 — Digital Signature
  • ● 0293 — Pseudo-Fortunate Numbers
  • ● 0297 — Zeckendorf Representation
  • ● 0303 — Multiples with Small Digits
  • ● 0304 — Primonacci
  • ● 0319 — Bounded Sequences
  • ● 0351 — Hexagonal Orchards
  • ● 0359 — Hilbert's New Hotel
  • ● 0387 — Harshad Numbers
  • ● 0457 — A Polynomial Modulo the Square of a Prime
  • ● 0473 — Phigital Number Base
  • ● 0487 — Sums of Power Sums
  • ● 0493 — Under the Rainbow
  • ● 0510 — Tangent Circles
  • ● 0521 — Smallest Prime Factor
  • ● 0531 — Chinese Leftovers
  • ● 0539 — Odd Elimination
  • ● 0545 — Faulhaber's Formulas
  • ● 0551 — Sum of Digits Sequence
  • ● 0555 — McCarthy 91 Function
  • ● 0565 — Divisibility of Sum of Divisors
  • ● 0612 — Friend Numbers
  • ● 0615 — The Millionth Number with at Least One Million Prime Factors
  • ● 0632 — Square Prime Factors
  • ● 0641 — A Long Row of Dice
  • ● 0650 — Divisors of Binomial Product
  • ● 0659 — Largest Prime
  • ● 0686 — Powers of Two
  • ● 0698 — 123 Numbers
  • ● 0731 — A Stoneham Number
  • ● 0745 — Sum of Squares II
  • ● 0787 — Bézout's Game
  • ● 0839 — Beans in Bowls
  • ● 0843 — Periodic Circles
  • ● 0853 — Pisano Periods 1
  • ● 0862 — Larger Digit Permutation
  • ● 0866 — Tidying Up B
  • ● 0875 — Quadruple Congruence
  • ● 0882 — Removing Bits
  • ● 0926 — Total Roundness
  • ● 0930 — The Gathering
  • ● 0932 — $2025$
  • ● 0934 — Unlucky Primes
  • ● 0935 — Rolling Square
  • ● 0936 — Peerless Trees
  • ● 0943 — Self Describing Sequences
  • ● 0944 — Sum of Elevisors
  • ● 0949 — Left vs Right II
  • ● 0950 — Pirate Treasure
  • ● 0951 — A Game of Chance
  • ● 0955 — Finding Triangles
  • ● 0957 — Point Genesis
  • ● 0963 — Removing Trits
  • ● 0967 — $B$-Trivisible Numbers
  • ● 0974 — Very Odd Numbers
  • ● 0987 — Straight Eight
  • ● 0996 — Overtakes
  • ● 1000 — Problem $1000$
  • ● 1003 — Lonely Singles