John Tromp's Blog

The largest number representable in 64 bits

2026-01-28T00:00:00+00:00

This post is a rewrite of my earlier blog post from Nov 2023 with many new insights and updates.

┬─┬ ┬─┬──────────                                  ┬─┬─┬ ┬─┬────────────
└─┤ │ │ ──┬──────                                  └─┤ │ │ │ ──┬────────
  │ │ │ ┬─┼──────                                    └─┤ │ │ ──┼─┬──────
  │ │ │ └─┤ ┬─┬──                                      │ │ │ ┬─┼─┼──────
  │ │ │   │ ┼─┼─┬                                      │ │ │ └─┤ │ ┬─┬──
  │ │ │   │ │ ├─┘                                      │ │ │   └─┤ ┼─┼─┬
  │ │ │   │ ├─┘                                        │ │ │     │ │ ├─┘
  │ │ │   ├─┘                                          │ │ │     │ ├─┘  
  │ │ ├───┘                                            │ │ │     ├─┘    
  │ ├─┘                                                │ │ ├─────┘      
  └─┘                                                  │ ├─┘            
                                                       └─┘              

Most people believe 2⁶⁴-1 = 18446744073709551615, or 0xFFFFFFFFFFFFFFFF in hexadecimal, to be the largest number representable in 64 bits. In English, it’s quite the mouthful: eighteen quintillion four hundred forty-six quadrillion seven hundred forty-four trillion seventy-three billion seven hundred nine million five hundred fifty-one thousand six hundred fifteen.

That is indeed the maximum possible value of 64 bit unsigned integers, available as data type uint64_t in C or u64 in Rust. Floating point data types can represent much larger values, courtesy of their base 2 exponent. The 64-bit double floating point format has a largest (finite) representable value of 2¹⁰²⁴(1-2^-53) ~ 1.8*10³⁰⁸.

What if we allow representations beyond plain data types? Since we want representations to remain computable, the most general kind of representation would be a program in some programming language. But the program must be small enough to fit in 64 bits.

The largest number programmable in 64 bits

The smallest possible valid C program is “main(){}”, consisting of 8 ASCII characters. ASCII is a 7-bit character encoding standard representing 128 unique characters, but all modern computers use 8-bit bytes to store either plain ASCII or UTF-8, a Unicode character encoding that’s backward compatible with ASCII. So we’ll consider the above all-scaffold do-nothing program to be the only valid 64-bit C program.

Plenty other languages require no such scaffolding. For instance, Linux features the arbitrary precision calculator bc. It happily computes the 954242 digit number 9^999999 = 35908462…48888889, making it programmable in 8 bytes. So is the much larger 9^9^9^99 = 9^(9^(9^99)) with over 10^10^94 digits, which bc is less happy to compute. If bc supported the symbol ! for computing factorials, then 9!!!!!!! would represent a much larger number still.

Allowing such primitives feels a bit like cheating though. Would we allow a language that has the Ackerman function predefined, letting the 8 byte expression ack(9,9) represent a truly huge number?

Ackerman considered unhelpful

As it turns out, the question is moot. One can blow way past ack(9,9) in under 64 bits in a language with no built in primitive whatsoever. A language with no basic arithmetic; not even numbers themselves. A language in which all those must be defined from scratch.

But let’s first look at another primitives-lacking language, one that has been particularly well studied for producing largest possible outputs. That is the language of Turing machines.

Busy Beaver

The famous Busy Beaver function, introduced by Tibor Radó in 1962, which we’ll denote BB(n), is defined as the maximal number of steps taken by an n-state Turing Machine (TM) with a binary tape alphabet, starting from an all 0 tape, before halting.

Here we have a discrepancy between how the size of a TM is measured, in states, versus how program size is measured, in bits. Fortunately there is a straightforward binary encoding of n-state TMs, which is entirely determined by its transition function. For each of the n states that the machine’s finite control can be in, and each of its 2 tape symbols that could be scanned by its tape head, the transition function specifies what new symbol to write in the scanned tape cell (1 bit), whether to move the tape head left or right (1 bit), and what new state (or special halt state) to transition to (⌈log2(n+1)⌉ bits). This encoding takes 6*2*(2+3) = 60 bits for a a 6-state TM, and 7*2*(2+3) = 70 bits for a a 7-state TM.

We’re also stretching the meaning of “representable” a bit, since BB considers the runtime of the machine instead of its output. Besides the above BB (that Radó called S), Radó did define another function called Σ that considers the output of the machine as a number in unary, namely the number of 1s in the final tape contents. But BB has received more attention as it allows one to determine from BB(n) all halting n-state machines. For 6-states and up though, there is no discernable difference in magnitude between the two functions so we could have just as easily used Σ.

So the largest number TM programmable in 64 bits is BB(6).

How large is BB(6)?

Unfortunately, we may never know. While all BB(n) have been determined (and even formally proven) for n≤5, there are some 6-state TMs whose halting behaviour are closely related to very hard mathematical problems. Most of these so-called cryptids are likely not to halt, with some, like Lucy’s Moonlight, likely to halt but unlikely to beat the current champion. The current 6-state champion shows that BB(6) > 2↑↑2↑↑2↑↑10 . Here, m↑↑n is Knuth’s up-arrow notation for an exponential tower of n m’s, so that for example 2↑↑3 = 2^2². Large as this number is, it’s still very small compared to ack(9,9) = 2↑⁷12 - 3 = 2↑↑↑↑↑↑↑12 - 3.

It is known however that BB(7) > 2↑¹¹2↑¹¹3 > ack(9,9) . Several leading BB researchers believe that BB(7) is even larger than the famous Graham’s Number, which iterates the function mapping n to 3↑ⁿ3 64 times starting from n=4. This appears to me a rather bold belief, considering that the smallest known Graham exceeding TM has 14 states, twice as many. So I offered a $1000 bet that a proof of BB(7) > Graham’s Number won’t be found within 10 years, which BB researcher Shawn Ligocki was happy to accept.

Meanwhile, Graham’s Number is easily surpassed within 64 bits, by moving beyond Turing machines into the language of

Lambda Calculus

Alonzo Church conceived the λ-calculus in about 1928 as a formal logic system for expressing computation based on function abstraction and application using variable binding and substitution.

The Graham beating lambda term originates in a Code Golf challenge asking for the “Shortest terminating program whose output size exceeds Graham’s number”, answered by user Patcail and further optimized by user 2014MELO03. The following 49 bit program

01 00 01 10 10 00 01 10 01 10 00 00 01 01 10 110 00 00 01 110 01 110 10

is the Binary Lambda Calculus encoding of the term

(λ 1 1) (λ 1 (1 (λ λ 1 2 (λ λ 2 (2 1)))))

where λ (lambda) denotes an anonymous function, and number i is the variable bound by the i-th nested λ. This is known as De Bruijn notation, a way to avoid naming variables. A more conventional notation using variable names would be

(λJ.J J) (λy.y (y (λg λm. m g (λf.λx.f (f x)))))

The top left of this post shows a graphical representation of the term. The last 16 bits of the program, making up almost a third of its size, encodes the term λf λx. f (f x), which takes arguments f and x in turn, and iterates f twice on x. In its generalized form, the function λf λx. fⁿ x, called Church numeral n, is the most common way of representing numbers in the λ-calculus. The encoding of Church numeral n is 0000(01110)ⁿ10, of size 5n+6 bits.

The program, which we’ll name after its discoverer, can be expressed more legibly as

Melo = let { 2 = λf λx. f (f x); H = λg λm. m g 2; J = λy. y (y H) } in J J

Melo evaluates to a Church numeral, “Melo’s Number”, that comfortably exceeds Graham’s Number.

Proof of exceeding Graham’s Number

Lemma 1. J J = 2↑↑6 HH 2, where HH denotes H H

Proof:

  J J
= J (J H)
= J (H HH)
= H HH (H HH H)
= H HH H            HH 2
= H HH 2            HH 2
= 2 HH 2            HH 2
= HH (HH 2)         HH 2
= HH 2          H 2 HH 2
= 2 H 2         H 2 HH 2
= H (H 2) H       2 HH 2
= H (H 2) 2       2 HH 2
= 2 (H 2) 2       2 HH 2
= H 2 (H 2 2)     2 HH 2
= H 2 2       2 2 2 HH 2
= 2 2 2       2 2 2 HH 2
= 2↑↑6              HH 2

Lemma 2. For k,n ≥ 2, k H 2 n > 3↑^k(1+n)

Proof:

By induction on k. First note that H2 n = H 2 n = n 2 2 = 2^2^n

Base: 2 H 2 n = H H2 n = n H2 2 = 2↑↑(1+2n) > 3↑²(1+n) already at n=2, since 2↑↑5 = 2^2^16 > 3^27 = 3↑↑3 Step: k+1 H 2 n = H (k H 2) n = n (k H 2) 2 > 3↑^k(1+ 3↑^k(1+ … 3↑^k(1+2)…)) > 3↑^k+1(1+n)

Lemma 3. For n ≥ 2, HH (HH n) > 3↑ⁿ3

Proof

By induction on n

Base: Lemma 1’s proof shows HH (HH 2) = 2↑↑6 > 3↑²3 Step: HH (HH 1+n) = HH 1+n H 2 = 1+n H 2 H 2 = H (n H 2) H 2 = H (n H 2) 2 2 = 2 (n H 2) 2 2 = n H 2 (n H 2 2) 2 >^Lm2 3↑ⁿ(1+3↑ⁿ(1+2)) 2 > 3↑ⁿ⁺¹3.

Theorem: J J > Graham’s Number G(64), where G(n) = n (\n -> 3↑ⁿ3) 4

Proof:

J J =^Lm1 2↑↑6 HH 2 >^Lm3 (2↑↑6 / 2 - 1) (\n -> 3↑ⁿ3) 3↑²3

(2↑↑6 / 2 - 1) (\n -> 3↑ⁿ3) 4 = G(2↑↑6 / 2 - 1) > G(64)

Leaving Melo’s Number in the dust

With 15 bits to spare, opportunities for vastly boosting Melo abound. Discord users 50_ft_lock and Sam found the following term that extends Melo’s H with an extra argument:

w218 = let { 2 = λf λx. f (f x); A = λa λb λc. c a b 2; T = λy. y (y A) } in T T T

which desugars to lambda term

(λT.T T T) (λy.y (y (λa λb λc. c a b (λf.λx.f (f x)))))

in conventional notation, or

(λ 1 1 1) (λ 1 (1 (λ λ λ 1 3 2 (λ λ 2 (2 1)))))

in de Bruijn notation, with 61-bit encoding

01 00 01 01 10 10 10 00 01 10 01 10 00 00 00 01 01 01 10 1110 110 00 00 01 110 01 110 10

Lemma 4. T T T = 2↑↑18 A 2 2 2 2 2 2 2 2 2 2

Proof: Let AA denote A A

  T T                                                            T
= T (T A)                                                        T
= T (A AA)                                                       T
= A AA (A AA A) T
= T AA                                                  (A AA A) 2
= AA (AA A) (A AA A)                                             2
= A AA A A                                              (AA A) 2 2
= A AA A 2                                              (AA A) 2 2
= 2 AA A                                              2 (AA A) 2 2
= AA (AA A) 2                                           (AA A) 2 2
= 2 A (AA A)                                          2 (AA A) 2 2
= A (A (AA A)) 2 (AA A)                                        2 2
= AA A (A (AA A))                                          2 2 2 2
= A (AA A) A A                                           2 2 2 2 2
= A (AA A) A 2                                           2 2 2 2 2
= 2 (AA A) A                                           2 2 2 2 2 2
= AA A (AA A A)                                        2 2 2 2 2 2
= AA A A                                         A A 2 2 2 2 2 2 2
= A A A 2                                        A A 2 2 2 2 2 2 2
= 2 A A                                        2 A A 2 2 2 2 2 2 2
= A AA 2 A                                         A 2 2 2 2 2 2 2
= A AA 2 2                                         A 2 2 2 2 2 2 2
= 2 AA 2                                         2 A 2 2 2 2 2 2 2
= AA (AA 2) 2                                      A 2 2 2 2 2 2 2
= 2 A (AA 2)                                     2 A 2 2 2 2 2 2 2
= A (A (AA 2)) 2 A                                   2 2 2 2 2 2 2
= A (A (AA 2)) 2 2                                   2 2 2 2 2 2 2
= 2 (A (AA 2)) 2                                   2 2 2 2 2 2 2 2
= A (AA 2) (A (AA 2) 2) 2                            2 2 2 2 2 2 2
= 2 (AA 2) (A (AA 2) 2) 2                            2 2 2 2 2 2 2
= AA 2 (AA 2 (A (AA 2) 2))                         2 2 2 2 2 2 2 2
= AA 2 (A (AA 2) 2)                          A 2 2 2 2 2 2 2 2 2 2
= A (AA 2) 2 A                           2 2 A 2 2 2 2 2 2 2 2 2 2
= A (AA 2) 2 2                           2 2 A 2 2 2 2 2 2 2 2 2 2
= 2 (AA 2) 2                           2 2 2 A 2 2 2 2 2 2 2 2 2 2
= AA 2 (AA 2 2)                        2 2 2 A 2 2 2 2 2 2 2 2 2 2
= AA 2 2                         A 2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= 2 A 2                        2 A 2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= A (A 2) 2 A                      2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= A (A 2) 2 2                      2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= 2 (A 2) 2 2                      2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= A 2 (A 2 2) 2                    2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= 2 2 (A 2 2) 2                    2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= 4 (A 2 2) 2                      2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= A 2 2 (A 2 2 (A 2 2 (A 2 2 2)))  2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= A 2 2 (A 2 2 (A 2 2 2))    2 2 2 2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= A 2 2 (A 2 2 2)      2 2 2 2 2 2 2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= A 2 2 2        2 2 2 2 2 2 2 2 2 2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= 2 2 2 2        2 2 2 2 2 2 2 2 2 2 2 2 2 2 A 2 2 2 2 2 2 2 2 2 2
= 2↑↑18 A 2 2 2 2 2 2 2 2 2 2

These 2↑↑18 iterations of A also let us relate its magnitude to the so-called Fast-growing hierarchy, a family that assigns, to each ordinal α, a function [α] (diverting from the usual f_α notation for improved legibility) from natural numbers to natural numbers. We’ll treat all numbers as Church Numerals, so we can write n f instead of the usual fⁿ and write f n instead of f(n) as normally done in λ-calculus.

Readers unfamiliar with ordinal arithmetic, may want to skip the next section.

The following FGH definition differs slightly from the standard one, which has the slightly slower growing [0] n = n+1 and [α+1] n = n [α] n. This allows Lemma 5 to be exact rather than a mere lower bound.

Definition of Fast Growing Hierarchy

[0] n = 2 n = n²
[α+1] n = n 2 [α] 2 = A 2 [α] n
[ωⁱ⁺¹(α+1)] n = [ωⁱ⁺¹α+ωⁱ n] 2

Lemma 5. For k≥0, n>=2, : k+1 A 2 [ω^k α] n = [ω^k (α+1)] n

Proof:

Base k=0: 0+1 A 2 [ω⁰ α] n = A 2 [α] n = n 2 [α] 2 = [α+1] n

Step k>0: k+1 A 2 [ω^k α] n = A (k A 2) [ω^k α] n = n (k A 2) [ω^k α] 2 = [ω^k α + ω^k-1 n] 2 = [ω^k (α+1)] n

Lemma 5 gives w218 = (2↑↑18 A 2 [0] 2) 2 2 2 2 2 2 2 = 2^2^2^2^2^2^2^([ω^2↑↑18-1] 2). In comparison, Graham’s and Melo’s Numbers are known to be much smaller at around [ω+1] 64 and [ω+1] (2↑↑6) respectively.

A Functional Busy Beaver

The λ-calculus analogue to BB is:

BBλ(n) = the maximum beta normal form size of any closed lambda term of size n

which appears in the Online Encyclopedia of Integer Sequences (OEIS) as functional Busy Beaver function Besides being simpler than BB, it has the advantage of using the standard unit of information theory, bits, rather than states.

The much more fine-grained use of bits allows the first 36 values of BBλ to be currently known, versus only 5 values of BB.

Since both are Church numerals, term Melo implies that BBλ(49) ≥ 5(Melo’s Number)+6, while w218 implies that BBλ(61) ≥ 5(2^2^2^2^2^2^2^([ω^2↑↑18-1] 2))+6.

BB compared bit-by-bit to BBλ

The growth rates of the two BB functions may be compared by how quickly they are known to exceed certain large number milestones, that correspond to well known ordinals in the Fast Growing Hierarchy.

For Graham’s Number, at ordinal ω+1, we saw earlier that Melo’s 49 bits compares with 14 states, which take 14*2*(2+4) = 168 bits to encode. If I lose my bet, then the comparison becomes rather closer at 49 vs 70 bits.

For Goodstein’s function at ordinal ε₀, 111 bits compares with 51 states taking 51*2*(2+6) = 816 bits.

The ε₀ growth term is actually obsoleted by a 100-bit term recently discovered by Patcail that grows at the unfathomably larger Bucholz’ Ordinal, the catching point between the SGH and the FGH. As such, that term easily exceeds another famously large number, TREE(3).

For the limit of Bashicu Matrix System (BMS), at (presumed) ordinal PTO(Z₂), 331 bits compares with 150 states taking 150*2*(2+8) = 3000 bits.

Finally, for Loader’s Number, at (presumed) ordinal PTO(Z_ω), 1850 bits compares with 1015 states taking 1015*2*(2+10) = 24360 bits.

One reason for TMs taking many more bits to achieve comparable growth, especially at the larger milestones, is the extremely poor programmability of TMs. The λ-calculus, despite its similar bare bones nature, doesn’t share this drawback. Modern high level pure functional languages like Haskell are essentially just syntactically sugared λ-calculus, with programmer friendly features like Algebraic Data Types translating directly through Scott encodings. The bruijn programming language is an even thinner layer of syntactic sugar for the pure untyped lambda calculus, whose extensive standard library contains many datatypes and functions. It is this excellent programmability of the λ-calculus that facilitated the construction of highly optimized programs for BMS and Loader’s.

Because programming a Turing machine is so impossibly tedious, that people have resorted to implementing higher level languages like Not-Quite-Laconic for writing nontrivial programs such as the TM that halts only upon finding an inconstency in ZFC. The above 1015 state TM for exceeding Loader’s Number even includes a λ-calculus interpreter written in NQL!

In his paper The Busy Beaver Frontier, Scott Aaronson tries to answer the question

But why Turing machines?

“For all their historic importance, haven’t Turing machines been completely superseded by better alternatives—whether stylized assembly languages or various codegolf languages or Lisp? As we’ll see, there is a reason why Turing machines were a slightly unfortunate choice for the Busy Beaver game: namely, the loss incurred when we encode a state transition table by a string of bits or vice versa. But Turing machines also turn out to have a massive advantage that compensates for this.”

Interesting behaviour at small sizes

“Namely, because Turing machines have no “syntax” to speak of, but only graph structure, we immediately start seeing interesting behavior even with machines of only 3, 4, or 5 states, which are feasible to enumerate.”

The number of uniquely behaving TMs with “only” 5 states is 4^10 * 632700 = 663434035200 , which is more than the number of closed lambda terms of size at most 52 bits (513217604750). The latter certainly exhibit no less interesting behaviour, so TMs hold no advantage here.

Ancient and fixed computational model

“And there’s a second advantage. Precisely because the Turing machine model is so ancient and fixed, whatever emergent behavior we find in the Busy Beaver game, there can be no suspicion that we “cheated” by changing the model until we got the results we wanted.”

The λ-calculus is just slightly more ancient and is arguably more fixed. There is no choice of tape alphabet size, no choice of whether the tape head needs to move in every transition, no choice of halting and output convention, and no choice in number of tapes or tape heads.

The λ-calculus can neither be suspected of being designed toward fast growth, so again TMs hold no advantage here.

The only remaining advantage of BB over BBλ is the many decades of research behind and publications about it.

A Universal Busy Beaver

Is BBλ then an ideal Busy Beaver function? Not quite. It’s still lacking one desirable property, namely universality.

This property mirrors a notion of optimality for shortest description lengths, where it’s known as the Invariance theorem:

Given any description language L, L_opt is at least as efficient as L, with at most constant additive overhead.

In the realm of beavers, this means we require of an optimal Busy Beaver BB_opt that it surpass any Busy Beaver function bb (based on self-delimiting programs) with at most constant lag:

for some constant c depending on bb, and for all n: BB_opt(n+c) ≥ bb(n)

While BBλ is not universal, the closely related

BBλ2(n) = the maximum output size of self-delimiting BLC programs of size n

achieves universality by giving λ-calculus terms access to pure binary data. BLC programs consist of an encoded lambda term, followed by arbitrary binary data, that the term is applied to.

Since (λ_. t) applied to any (standard lambda representation of) binary data equals t, BBλ champions provide lower bounds for BBλ2: for all n, BBλ2(2+n) ≥ BBλ(n).

In conclusion

The largest number (currently known to be) representable in 64 bits is w218, which lower bounds both BBλ(61) and BBλ2(63).

Nesting interpreters

2026-01-16T00:00:00+00:00

Nesting interpreters

A friend of mine enquired about my experience with Lévy-optimal evaluation of lambda calculus, to which I replied:

I've tried various others and found them horribly slow
on actual benchmarks despite their optimality.
So I prefer simple (and hence non-opimal) runtimes that are pretty
quick in practice, namely combinator graph reduction such as
https://github.com/augustss/MicroHs or my own
https://github.com/tromp/AIT/blob/master/uni.c

There's one thing that I really would like to get more optimal though.
What I notice with combinatory reducers is that you can run nested
binary combinatory logic interpreters
with only additive overhead; each additional interpreter basically
rewrites itself into the higher level one.
That is not the case with all the binary lambda calculus interpreters
I tried, even the ones based on
Kiselyov's direct translation
https://theory.stanford.edu/~blynn/lambda/kiselyov.html

I'd like to know if that is fundamentally impossible or not.

My friend understandably asked for clarification on the nesting of interpreters and additive overhead, and while pondering a reply, I realized this might be of interest to more people, so I decided to make a blog post about it.

Universal Lambda Machine

To dive straight in, I’ve proposed a ULM [1] [2] that reads from a binary input stream an encoded lambda term, and applies it to the remainder of input.

When the encoded term is itself a lambda calculus interpreter operating as a universal lambda machine, then the ULM’s behaviour on the remaining input is identical to its original behaviour.

Except when behaviour includes performance on actual hardware. Nesting interpreters normally incur a constant factor slowdown or worse.

This was already noted in my 2012 IOCCC submission where a “Performance” section [4] compares runtimes with 0,1,2,3, and 4 nested interpreters running a prime number sieve, incurring slowdowns of respectively 4.4x, 10.0x, 12.2x, and 12.4x.

Let’s rerun that experiment with the much more performant (and compilable) uni.c runtime [4], and with a simpler end-task resulting in a normal form:

$ (cat delimit.blc; echo -n 1111000111001) | ../uni -b
11010steps 9746 time 0ms steps/s 666M #GC 0 HP 20492
$ (cat uni.blc delimit.blc; echo -n 1111000111001) | ../uni -b
11010steps 143176 time 3ms steps/s 47M #GC 0 HP 159806
$ (cat uni.blc uni.blc delimit.blc; echo -n 1111000111001) | ../uni -b
11010steps 1554114 time 36ms steps/s 43M #GC 1 HP 539112
$ (cat uni.blc uni.blc uni.blc delimit.blc; echo -n 1111000111001) | ../uni -b
11010steps 17928565 time 407ms steps/s 44M #GC 18 HP 282330
$ (cat uni.blc uni.blc uni.blc uni.blc delimit.blc; echo -n 1111000111001) | ../uni -b
11010steps 209071006 time 5047ms steps/s 41M #GC 233 HP 518110
$ (cat uni.blc uni.blc uni.blc uni.blc uni.blc delimit.blc; echo -n 1111000111001) | ../uni -b
11010steps 2439995720 time 69617ms steps/s 35M #GC 3407 HP 940096

File uni.blc contains the 196 bit encoding of the universal lambda term (λ11)(λ(λλλ1(λλ2(1(λ6(λ2(6(λλ3(λλ23(14))))(7(λ7(λ31(21)))))))(41(111))))(11))(λ1((λ11)(λ11))).

The delimit program decodes the Levenshtein encoding [5] 1111000111001 of the binary string 11010. Now we see step slowdowns of 14.7x, 10.9x, 11.5x, 11.7x, and 11.7x.

Now to make the experiment vastly more interesting, let’s try nesting binary combinatory logic interpreters instead.

$ (cat uniSK.blc delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 62490 time 1ms steps/s 62M #GC 0 HP 78802
$ (cat uniSK.blc uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 119378 time 2ms steps/s 59M #GC 0 HP 127812
$ (cat uniSK.blc uniSK.bcl uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 158725 time 3ms steps/s 52M #GC 0 HP 145464
$ (cat uniSK.blc uniSK.bcl uniSK.bcl uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 201786 time 4ms steps/s 50M #GC 0 HP 163116
$ (cat uniSK.blc uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 248561 time 4ms steps/s 62M #GC 0 HP 180768
$ (cat uniSK.blc uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 299050 time 5ms steps/s 59M #GC 0 HP 198420
$ (cat uniSK.blc uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 353253 time 6ms steps/s 58M #GC 0 HP 216072
$ (cat uniSK.blc uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 411170 time 7ms steps/s 58M #GC 0 HP 233724
$ (cat uniSK.blc uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl uniSK.bcl delimit.bcl; echo -n 1111000111001) | ../uni -b
11010steps 472801 time 8ms steps/s 59M #GC 0 HP 251376

Shockingly, the constant factor slowdown is gone! The slowdown is now more like an additive one, of 56888, 39347, 43061, 46775, 50489, 54203, 57917, and 61631 steps.

Two contributing factors make this possible. First, uni.c is a combinatory graph reducer, bulding an acyclic graph of binary application nodes and combinator leaves, and repeatedly rewriting the graph for combinators applied to sufficiently many arguments. For a combinator that duplicates arguments, such as S x y z = x z (y z), the z node will be shared as the right child of both the (newly created) application nodes for x z and for y z.

Second, the combinatory logic binary encoding is exceedingly simple, using 1 for (prefix [6]) application, 10 for K, and 11 for S, allowing for a very simple interpreter that immediately passes an encoded combinator to a given continuation after reading its code.

Combined, this means that the graph of the interpreter, applied to the graph representing the input stream of bits, ends up rewriting itself back to the graph of the interpreter. Or mostly, considering the step difference still increases.

The lambda calculus interpreters are not quite so straightforward. After reading the code of a term, what they pass to the given continuation is a function that maps an environment of free variables to the encoded term. This extra mapping prevents the combinator graph from just rewriting itself.

I had hoped that a more direct translation from encoded lambda terms to combinators, based on Oleg Kiselyov’s work [7], could also avoid the constant factor slowdown, but sadly that was not the case.

Future work

If we replaced the uni.c runtime with a Lévy-optimal lambda evaluator, then supposedly we should see additive slowdowns, at least in terms of number of beta reductions performed. But we may also see constant factor slowdowns in the number of beta reductions performed per second, negating the former. Hopefully we will see more performant optimal evaluators in future, perhaps based on interaction nets [8], to continue these experiments with.

I’ve started work on a binary language that is a hybrid of lambda calculus and combinatory logic, tentatively called Binary Combinatory Lambda Calculus, or BCLC. It encodes application as 001, K as 010, S as 011, abstraction as 000, and a De Bruijn index as 1^i0. This allows one to slowly morph a combinatory logic interpreter into a lambda calculus interpreter, and see where the “phase transition” from additive slowdown to constant factor slowdown occurs.

References

[1] Most functional

[2] Universal Lambda Machine

[3] Performance

[4] uni.c

[5] Levenshtein code

[6] Polish notation

[7] Kiselyov Combinator Translation

[8] Interaction Nets

Gaming the coordinates

2024-04-15T00:00:00+00:00

Sensei’s library [1] lists several coordinate systems for the standard 19x19 size Go board. The system shown above must rank as one of the more unusual ones.

It was inspired by a recent email from fellow games researcher Ryan Hayward [2], in which he noticed that a triangle shaped board on just 3 points, has precisely 19 legal positions, as well as 3439 legal games (under the Logical rules [3]).

Having studied Hamiltonian games in our Combinatorics of Go paper [4], I was naturally curious to see if triangular Go was also Hamiltonian. That is, whether one can play a game that visits all legal positions.

As it turns out, not only can one do so, but (up to symmetry) the game is unique and has no intermediate passes!

That makes it quite natural to use the 19 successive positions in that game as coordinates to mark the successive vertical lines of the Go board. We similarly mark successive horizontal lines of the Go board, except for flipping the triangles upside-down, so that x and y coordinates nicely align into a slanted 2x3 grid, as shown for example with tengen coordinates

Curiously, the star points are exactly those, both of whose coordinates have 2 black stones.

Obviously this is not the most practical of coordinate systems, but it does have a certain aesthetic appeal…

[1] Sensei’s Library

[2] Ryan Hayward

[3] The Logical rules of Go

[4] Combinatorics of Go

The largest number representable in 64 bits

2023-11-24T00:00:00+00:00

A rewrite of this blog post with many new insights and updates appeared in Jan 2026

┬─┬─────────┬─┬─┬ ┬─┬──
└─┤ ──┬──── │ │ │ ┼─┼─┬
  │ ──┼─┬── │ │ │ │ ├─┘
  │ ┬─┼─┼─┬ │ │ │ ├─┘  
  │ └─┤ │ │ │ │ │ │    
  │   └─┤ │ │ │ │ │    
  │     ├─┘ │ │ │ │    
  └─────┤   │ │ │ │    
        └───┤ │ │ │    
            └─┤ │ │    
              └─┤ │    
                └─┘    

That is indeed the maximum possible value of 64 bit unsigned integers, available as datatype uint64_t in C or u64 in Rust. We can easily surpass this with floating point numbers. The 64-bit double floating point format has a largest (finite) representable value of 2¹⁰²⁴(1-2^-53) ~ 1.8*10³⁰⁸.

What if we allow representations beyond plain datatypes? Such as a program small enough to fit in 64 bits. For most programming languages, there is very little you can do in a mere 8 bytes. In C that only leaves you with the nothingness of “main(){}”.

But there are plenty languages that require no such scaffolding. For instance, on Linux there is arbitrary precision calculator “bc”. It happily computes the 954242 digit number 9^999999 = 35908462…48888889, which can thus be said to be representable in 64 bits. Had it supported the symbol ! for computing factorials, then 9!!!!!!! would make a much larger number representable in 64 bits.

Allowing such primitives feels a bit like cheating though. Would we allow a language that has the Ackerman function predefined, which sports the 8 byte expression ack(9,9) representing a truly huge number?

No primitives needed

As it turns out, the question is moot. There are simple languages with no built in primitives. Not even basic arithmetic. Not even numbers themselves. Languages in which all those must be defined from scratch. One such language allows us to blow way past ack(9,9) in under 64 bits.

But let’s first look at another such language, one that has been particularly well studied for producing largest possible outputs. That is the language of Turing machines.

Busy Beaver

The famous Busy Beaver function, introduced by Tibor Radó in 1962, which we’ll denote BB_TM(n), is defined as the maximum number of 1s that can be written with an n state Turing machine starting from an all 0 tape before halting. Note that if we consider this output as a number M written in binary, then it only gets credited for its length, which is log₂(M+1).

In 64 bits, one can fully specify a 6 state binary Turing machine, or TM for short. For each of its internal states and each of its 2 tape symbols, one can specify what new tape symbol it should write in the currently scanned tape cell, whether to move the tape head left or right, and what new internal state, or special halt state, to transition to. That takes 6*2*(2+⌈log2(6+1)⌉) = 60 bits. Just how big an output can a 6 state TM produce?

The best known result for 6 states is BB_TM(6) > 10↑↑15, which denotes an exponential tower of fifteen 10s. Clearly, in this notation there’s not that much difference between a number and its size in bits. Large as this number is, it’s still pathetically small compared to even ack(5,5), which no known TM of less than 10 states—amounting to 110 bits of description—can surpass.

For that, we need to move beyond Turing machines, into the language of

Lambda Calculus

Alonzo Church conceived the λ-calculus in about 1928 as a formal logic system for expressing computation based on function abstraction and application using variable binding and substitution.

A tiny 63 bit program in this language represents a number unfathomably larger than not only ack(9,9), but the far larger Graham’s Number as well. It originates in a Code Golf challenge asking for the “Shortest terminating program whose output size exceeds Graham’s number”, answered by user Patcail and further optimized by user 2014MELO03. With one final optimization applied, the following 63 bit program

01 00 01 01 01 01 01 10 10 00 00 00 01 01 01 10 1110 110 10 10 10 10 00 00 01 110 01 110 10

is the Binary Lambda Calculus encoding of the term

(λ 1 1 (λ λ λ 1 3 2 1) 1 1 1) (λ λ 2 (2 1))

(λt. t t (λh λf λn. n h f n) t t t) (λf λx. f (f x))

The top of this post shows a graphical representation of the term. The last 16 bits of the program—making up more than a quarter of its size—encodes the term λf λx. f (f x), which takes arguments f and x in turn, and iterates f twice on x. In general, the function that iterates a given function n times on a given argument is called Church numeral n, and is the standard way of representing numbers in the λ-calculus. The program, which we’ll name after its underlying growth rate, can be expressed more legibly as

wCubed = let { 2 = λf λx. f (f x); H = λh λf λn. n h f n } in 2 2 H 2 2 2

The next section is mostly for the benefit of readers familiar with ordinal arithmetic, and is probably better skipped by others.

Proof of exceeding Graham’s Number

Following the great suggestion of Googology user “BMS is not well-founded”, let us start by defining a wCubed-customized Fast-growing hierarchy, a family that assigns, to each ordinal α, a function [α] (diverting from the usual f_α notation for improved legibility) from natural numbers to natural numbers. We’ll treat all numbers as Church Numerals, so we can write n f instead of the usual fⁿ and write f n instead of f(n) as normally done in λ-calculus.

Definitions:

H h f n = n h f n
H2 = H 2
[0] n = 2 n = n²
[α+1] n = n 2 [α] n = H 2 [α] n
[ωα+ω] n = [ωα+n] n
[ωⁱ⁺¹(α+1)] n = [ωⁱ⁺¹α+ωⁱ n] n

Lemmas:

2 H 2 [ω i] n = H H2 [ω i] n =^{(Def. 1)} n H2 [ω i] n =^{(n x Def. 4)} [ω i+n] n =^{(Def. 5)} [ω(i+1)] n
3 H 2 [ω²i] n = H (2 H 2) [ω²i] n =^{(Def. 1)} n (2 H 2) [ω²i] n =^{(n x Lemma 1)} [ω²i+ω n] n =^{(Def. 6)} [ω²(i+1)] n
4 H 2 [0] n = H (3 H 2) [0] n =^{(Def. 1)} n (3 H 2) [0] n =^{(n x Lemma 2)} [ω²n] n =^{(Def 6)} [ω³] n

Lemma 3 gives wCubed = 2 2 H 2 2 2 = 4 H 2 [0] 2 = [ω³] 2. In comparison, Graham’s number is known to be less than the much much smaller [ω+1] 64. As it turns out, this proof becomes almost trivial in our custom hierarchy. We start with defining Graham’s number as a Church numeral, exploiting the fact that in Knuth’s up-arrow notation, 3 ↑ n = 3ⁿ = upify (mult 3) n, and 3 ↑^k+1 n = (3 ↑^k )^n-1 3 = (3 ↑^k )^n-1 (3 ↑^k 1) = (3 ↑^k )ⁿ 1:

Definitions:

mult a b f = a (b f)
upify f n = n f 1
g n = n upify (mult 3) 3
Graham = 64 g 4

Lemmas (assuming n ≥ 3):

times 3 n ≤ n² = [0] n
upify [α] n = n [α] 1 < 2 n [α] 1 = [α+1] n
g n = n upify (times 3) 3 ≤^{(Lemma 1)} n upify [0] 3 <^{(Lemma 2)} f_n n = [ω] n

By Lemma 3, Graham = 64 g 4 < 64 [ω] 64 = [ω+1] 64

A Functional Busy Beaver

Based on the λ-calculus, I recently added to OEIS a functional Busy Beaver function BB_λ that, besides greater simplicity, has the advantage of measuring program size in bits rather than states. Note how, similar to BB_TM(), the value of BB_λ() is not the program output considered as a number itself, but rather the output size. And in case of binary λ-calculus, the size of a Church numeral n is 5n+6. The first unknown BB_TM is at 5 states, while the first unknown BB_λ is at 37 bits.

The growth rates of the two BB functions may be compared by how quickly they exceed that most famous of large numbers: Graham’s number. The current best effort for BB_TM, after many rounds of optimization, is stuck at 16 states, weighing in at over 16*2*(2+4) = 192 bits. That compares rather unfavorably with our 63 bits.

The existence of a 29 bit Ackermann-like function and a 79 bit function growing too fast to be provably total in Peano Arithmetic, also have no parallels in the realm of Turing machines, suggesting that the λ-calculus exhibits faster growth.

It further enjoys massive advantages in programmability. Modern high level pure functional languages like Haskell are essentially just syntactically sugared λ-calculus, with programmer friendly features like Algebraic Data Types translating directly through Scott encodings. The bruijn programming language is an even thinner layer of syntactic sugar for the pure untyped lambda calculus, whose extensive standard library contains many datatypes and functions. It is this excellent programmability of the λ-calculus that facilitated the creation of wCubed.

In contrast, programming a Turing machine has been called impossibly tedious, which explains why people have resorted to implementing higher level languages like Not-Quite-Laconic for writing nontrivial programs that don’t waste too many states.

In his paper The Busy Beaver Frontier, Scott Aaronson tries to answer the question

But why Turing machines?

For all their historic importance, haven’t Turing machines been completely superseded
by better alternatives—whether stylized assembly languages or various codegolf languages or Lisp?
As we’ll see, there is a reason why Turing machines were a slightly unfortunate choice
for the Busy Beaver game: namely, the loss incurred when we encode a state transition table
by a string of bits or vice versa.
But Turing machines also turn out to have a massive advantage that compensates for this.
Namely, because Turing machines have no “syntax” to speak of, but only graph structure,
we immediately start seeing interesting behavior even with machines of only 3, 4, or 5 states,
which are feasible to enumerate.
And there’s a second advantage. Precisely because the Turing machine model is so ancient and fixed,
whatever emergent behavior we find in the Busy Beaver game, there can be no suspicion that
we “cheated” by changing the model until we got the results we wanted.
In short, the Busy Beaver game seems like about as good a yardstick as any for gauging humanity’s
progress against the uncomputable

The claimed advantages for the “slightly unfortunate choice” do not hold over that even more ancient model of the λ-calculus, while the latter’s relatively straightforward binary encoding make it a preferable yardstick for exploring the limits of computation. The real question then is “Why not λ-calculus?”, the answer to which appears to be rooted in historical accident more than anything.

A Universal Busy Beaver

Is BB_λ then an ideal Busy Beaver function (apart from a historical lack of study)? Not quite. It’s still lacking one desirable property, namely universality.

This property mirrors a notion of optimality for shortest description lengths, where it’s known as the Invariance theorem:

Given any description language L, the optimal description language is at least as efficient as L, with some constant overhead.

In the realm of beavers, this means that given any Busy Beaver function BB (based on self-delimiting programs), an optimal Busy Beaver surpasses it with at most constant lag:

for some constant c depending on BB, and for all n: BB_opt(n+c) ≥ BB(n)

While BB_λ is not universal, it’s not far from one either. By giving λ-calculus terms access to pure binary data, as in the Binary Lambda Calculus, function BB_BLC achieves universality while lagging only 2 bits behind BB_λ. It’s known to eventually outgrow the latter, but that could take thousands of bits.

Besides having a somewhat more complicated definition, and being somewhat harder to analyze, BB_BLC has one other downside: it doesn’t represent the ginormous wCubed in 64 bits…

John adds blog

2023-11-20T00:00:00+00:00

Well. Finally got around to putting this blog site together. Using these helpful instructions by Denis Bakhvalov.

View my feed.

Flip Puzzles and Linear Algebra

2021-12-18T00:00:00+00:00

This post discusses how to solve flip puzzles like Simon Tatham’s “Flip” [1] or David Johnson-Davies’s 16 LEDs puzzle [2], where each cell in a rectangular grid represents a light that can be either on or off, and the goal is to have all lights turned on.

The challenge is that, while each light can be flipped by clicking on its cell (or pressing a button directly below the LED), this action also flips several other lights in a certain pattern.

Because the LED puzzle uses diagonals through a cell as patterns, this decomposes the 16 LEDs puzzle into 2 disjoint 8 LEDs puzzles:

_ A _ B                 H _ I _
C _ D _                 _ J _ K
_ E _ F                 L _ M _
B _ G _                 _ N _ O

according to the light and dark squares in a checkerboard pattern. Let’s focus on the 8 LEDs puzzle on the left, with the 8 lights marked as A..G. If we denote the corresponding switches in lowercase a..g, then the behavior of light A can be described as A = a + c + d + f, since pressing any of these 4 switches will flip light A, and the other switches have no effect on A. A switch takes on value 0 if not pressed, and 1 if pressed. Furthermore, since flipping twice is the same as not flipping, we add modulo 2, where 1 + 1 = 0. Mathematicians call this number system GF(2). The behavior of all 8 light can now be expressed in a single matrix equation

 A   ( 1 0 1 1 0 1 0 )   a
 B   ( 0 1 0 1 1 0 0 )   b
 C   ( 1 0 1 0 1 0 1 )   c
 D = ( 1 1 0 1 1 1 0 )   d
 E   ( 0 1 1 1 1 0 1 )   e
 F   ( 1 0 0 1 0 1 1 )   f
 G   ( 0 0 1 0 1 1 1 )   g

This matrix over GF(2) is not invertible; its rank is only 5, so the lights cannot be changed arbitrarily. By Gaussian elimination [3], one finds that switch f does the same as switches a+b+e, and button g the same as b+c+d. This means there’s no need to use these switches (f=g=0) and the matrix equation simplifies to

A   ( 1 0 1 1 0 )   a
B   ( 0 1 0 1 1 )   b
C = ( 1 0 1 0 1 )   c
D   ( 1 1 0 1 1 )   d
E   ( 0 1 1 1 1 )   e

Using Linear Algebra, we can invert the matrix [4] and express the switch values in terms of the light values:

a   ( 0 1 0 1 0 )   A
b   ( 1 1 1 0 0 )   B
c = ( 0 1 0 0 1 )   C
d   ( 1 0 0 1 1 )   D
e   ( 0 0 1 1 1 )   E

So if the puzzle has only lights A and E off, and we want to know what switches to press to flip these two lights and no others, then we compute the sum of the 1st and 5th column of the matrix:

 ( 0 1 0 1 0 )   1
 ( 1 1 1 0 0 )   0
= ( 0 1 0 0 1 )   0
 ( 1 0 0 1 1 )   0
 ( 0 0 1 1 1 )   1

to find that switches b, c, and e must be pressed. Indeed:

_ 0 _ 1       _ 1 _ 0       _ 0 _ 1         _ 1 _ 0
0 _ 1_        1 _ 0 _       1 _ 1 _         0 _ 0 _
_ 1 _ 0   +   _ 1 _ 0   +   _ 1 _ 0    =    _ 1 _ 0
1 _ 0 _       0 _ 1 _       1 _ 1 _         0 _ 0 _
   b             c             e

Happy flipping!

[1] https://www.chiark.greenend.org.uk/~sgtatham/puzzles/js/flip.html

[2] http://www.technoblogy.com/show?3PO0

[3] https://en.wikipedia.org/wiki/Gaussian_elimination

[4] https://en.wikipedia.org/wiki/Gaussian_elimination#Finding_the_inverse_of_a_matrix

SK numerals

2021-11-05T00:00:00+00:00

Church Numerals

Church numerals are the standard way of representing natural numbers in the lambda calculus. Cn, the Church numeral for n, iterates a given function n times on a given argument. So we have

C0 f x = f⁰ x = x
C1 f x = f¹ x = f x
C2 f x = f² x = f (f x)

etcetera. We can define a successor function “Csucc” which iterates a given function one more time than a given numeral does:

Csucc = λn.λf.λx. f (n f x)

(λn.λf.λx. n f (f x) works equally well). Each Church numeral Cn is thus itself the n’th iterate of Csucc on C0:

Cn = Cn Csucc C0

The best thing about Church numerals is the ease of defining arithmetic operators. It is straightforward to verify that

add = λm.λn.λf.λx. m f (n f x)
mul = λm.λn.λf. m (n f)
pow = λm.λn. n m

work as advertised.

E.g. pow C2 C3 = C3 C2 = λf. C2 (C2 (C2 f)) = λf.((f²)²)² = λf.f⁸ = C8

Much less straightforward is the predecessor operator, that takes C(n+1) to Cn and leaves C0 unchanged:

Cpred = λn.λf.λx. n(λg.λh. h(g f))(λu. x)(λu. u)

Wikipedia tries to explain its operation in detail.

Even less straightforward is the following division operator that springs from the creative mind of Bertram Felgenhauer:

div = λn.λm.λf.λx.n(λx.λf.f x)(λd.x)(n (λt.m(λx.λf.f x)(λc.f(c t))(λx.x))x)

whose operation is illustrated in this Algorithmic Information Theory github repository.

SK Combinatory Logic

Combinatory Logic is concerned with terms consisting of the 2 basic combinators

S = λx.λy.λz. x z (y z)
K = λx.λy. x

combined through application. It turns out that any closed lambda term is equivalent to a combinator. For example, the identity combinator can be obtained as

I = S K K

since I x = S K K x = K x (K x) = x.

While reading Stephen Wolfram’s latest book, I came across an interesting alternative to Church numerals for Combinatory Logic:

F0 = K
F1 = S K
F2 = S (S K)
F3 = S ( S (S K)))

etcetera, so S iterated n times on K, or Fn = Cn S K.

This takes economy to an extreme, by using the 2 primitive combinators S and K as the very building blocks of numbers:

F0 = K
Fsucc = S

We have

F0 x y = x
F(n+1) x y = S Fn x y = Fn y (x y)

so that

F1 x y = y
F2 x y = x y
F3 x y = y (x y)
F4 x y = x y (y (x y))

etcetera, which can be shown by induction so satisfy the Fibonacci recurrence

F(n+2) x y = (Fn x y) (F(n+1) x y)

with sum replaced by application! Consequently, there are exactly fib(n) occurrences of variable y in Fn x y.

In honor of this close connection we denote these SK numerals with the letter F . Curiously, F0 and F1 coincide with the standard representations of booleans

True = K
False = S K

The big question, though, is whether they work as numerals. The ultimate test of that is the ability to convert them back into Church numerals. Wolfram’s book suggests a way to do that by applying an SK numeral to x and y that are both Church numerals, perhaps C3 and C2, which leads to all applications working as powers. For example, F3 C3 C2 = C2 (C3 C2) = C2 C8 = C256. And from that we could work our way back to the 3, resulting in a size 181 conversion combinator.

A more elegant conversion can be obtained by defining predecessor and iszero operators, and using these to count down to zero

Fpred = λn.λx.λy. n (K y) x
Fiszero = λn. n False I S K
F2C = λn. Fiszero n C0 (Csucc (F2C (pred n)))

We may check that

Fpred (Fsucc n) = \x\y. S n (K y) x = \x\y. n x y = n

so Fpred F(n+1) = Fn for all n.

Fiszero works as follows:

Fiszero F0 = F0 False I S K = False S K = K = True
Fiszero F(n+1) False I S K = S Fn False I S K = Fn I I S K = I S K = S K = False

While Fpred lets us define negative numbers as well:

F-1 x y = Fpred F0 x y = F0 (K y) x = K y
F-2 x y = Fpred F-1 x y = F-1 (K y) x = K x
F-3 x y = Fpred F-2 x y = F-2 (K y) x = K (K y)

Fsucc doesn’t work on these, so they’re mostly useless.

Using the optimal Y combinator S S K (S (K (S S (S (S S K)))) K), F2C is combinator of size 69, a huge improvement.

But it turns out we can do better still, courtesy of good old Bertram:

pair = λx.λy. λp. p x y
F2C = λn.(λp. n p(p p) False) (pair (λf.λy.λx. pair f (Csucc y)) C0)

This size 58 combinator

S (S (K (S S (K (K (S K))))) (S S (K (S I I)))) (K (S (S I (K (S (K (S (K (S S (K (S (S (K S) K))))) K)) (S (K (S (K (S (K (S (K (S (K (S S (K K))) K)) (S (K K)))) S)) (S I))) K)))) (K (S K))))

applies the SK numeral to x and y that are both pairs of some function and a church numeral. Applying one such pair to another results in the function applied to itself and the two numerals:

(pair f Cm) (pair f Cn) = (pair f Cn) f Cm = f f Cn Cm

so all function f has to do is take the successor of the right Church numeral and wrap it back up into a pair. In the F2C definition above, p is a wrapped C0 and (p p) becomes a wrapped C1.

And that wraps us our brief exploration of SK numerals.

A case for using soft total supply.

2020-12-20T00:00:00+00:00

The cryptocurrency space features endless debates about the pros and cons of various possible emission curves. Prime among them is question of whether supply should be capped (finite) or uncapped (infinite). But is this really an essential difference?

It doesn’t take much to change a finite supply into an infinite one. Bitcoin’s block reward drops from 1 satoshi to 0 satoshi somewhere in the year 2140, completing a supply of approximately 21 million bitcoin [1]. What if that final drop never happened?

Bitcoin would continue emitting a 1 satoshi block reward in perpetuity, yielding an infinite supply. It would eventually reach 21 million + 1 bitcoin. Let’s see when that happens. We need to wait an additional 100 million blocks, which takes approximately 10⁸/6/24/365 = 1902 years.

Would that make make Bitcoin any less hard a currency? I don’t think anyone would be willing to argue that. So what makes a currency hard, if not a capped supply? I think the answer is obvious. Eventual negligible inflation is what makes for hard currency. It is what distinguishes cryptocurrencies from fiat.

How low should inflation be to be considered negligible? There are two related measures for quantifying this. One is the yearly supply inflation rate, commonly used for fiat currencies. The other is its inverse, stock-to-flow ratio, the ratio between existing supply (stock) and the supply to be added in the next year (flow). This measure is popular for commodities. As discussed more extensively in [2], bitcoin’s inflation rate fell below 2% in 2020, and will fall below that of Gold in the next few years.

As long as the block reward (flow) never increases, then just by having supply increase every year, the inflation rate will naturally fall towards zero. The technical term for this is “disinflationary”. The inflation rate never reaches 0, but it gets arbitrarily close.

In cryptocurrency practice though, it doesn’t matter whether inflation has reached 0.1% or 0.01%. And that is because unlike Gold, it’s rather easy to lose cryptocurrency. Estimates for the fraction of all Bitcoin that is forever lost range from 15% to as much as 25%. People forget or lose passwords or take them to the grave. People accidentally erase wallet files. People accidentally send bitcoin to obsolete addresses, or straight into the void. People explicitly burn bitcoin. With newer coins, standards for recovery phrases, more mature software and hardware wallets, we can expect much lower loss percentages, but getting the yearly loss rate significantly below 1% will remain a challenge.

This motivates a definition of the “soft” end of emission as the time when the inflation rate drops below 1%, and the soft (total) supply as the supply at the time. At this time, new supply more or less balances the inevitable ongoing loss of coins. After its 4th halving in 2024, bitcoin will reach the soft end of its emission with a soft supply of (15/16) * 21M = 19.6875M BTC. At the extreme end of slow emissions is Grin. Its pure linear emission of 1 Grin per second forever, will reach its soft supply of a century (100*365*24*60*60s) of Grin, only in 2119.

This allows for a sensible supply comparison of nearly all coins. The only coins with uncapped soft supply are those with some explicit positive percentage growth rate, such as what fiat currencies aim for. I think there are only a handful of proof-of-stake coins that fall into that category. For all others, it gives a sensible measure of how far along a coin is in its emission. Using soft supply, a daily dollar issuance ranking like [3] would no longer need to show infinities for remaining supply of coins with a tail emission.

[1] https://medium.com/amberdata/why-the-bitcoin-supply-will-never-reach-21-million-7263e322de1

[2] https://medium.com/the-capital/stock-to-flow-ratio-why-bitcoins-value-increases-after-each-halving-d08c23d46a08

[3] https://www.f2pool.com/coins

Beyond the Hashcash Proof-of-Work (there’s more to mining than hashing)

2015-09-07T00:00:00+00:00

Many people equate Proof of Work (PoW) with one particular instance of it. It’s not hard to understand why. The Hashcash PoW is used not only in Bitcoin but in the vast majority of altcoins as well.

In Hashcash, miners all compete to look for a so called `nonce’ which, if provided as input (together with other parts of a block header) to a hash function, yields an output that’s numerically small enough to claim the next block reward.

Where most crypto currencies differ is in the choice of hash function; the Hashcash flavor as it were. Besides Bitcoin’s `vanilla’ flavor of SHA256, there is Litecoin’s scrypt, Cryptonote’s CryptoNight, Darkcoin’s X11, and many more. Most alternative flavors have the explicitly stated goal of reducing the performance gap between custom and commodity hardware, either by use of memory, or by sheer complexity.

But miners are only part of the picture. Proofs of work must not only be found, but verified as well, by every single client, including smartphones and other devices with limited resources. In Hashcash, verification amounts to evaluating the hash function on the given nonce and comparing the output with the difficulty threshold. Which is exactly the same effort as a single proof attempt.

Thus, in order to keep verification cheap, hash functions in Hashcash must restrict their resource usage as well. That’s why scrypt is configured to use only 128KB of memory.

Non-Hashcash PoWs do not suffer this limitation; they are asymmetric, with verification much cheaper than proof attempt. The first such PoW is Primecoin, which finds chains of nearly doubled prime numbers. The most recent example is my Cuckoo Cycle PoW, which was presented at the BITCOIN’2015 workshop in January. The whitepaper can be found at github.com/tromp/cuckoo, which also hosts various implementations, as well as bounties for improving on them.

In Cuckoo Cycle, proofs take the form of a length 42 cycle (loop) in a large random graph defined by some nonce. Imagine two countries, each with a billion cities, and imagine picking a billion border crossing roads that connect a random city in one country to a random city in the other country (the PoW actually uses a cheaply computed hash function to map the nonce, road number, and country to a city). We are asked if there is cycle of 42 roads visiting 42 different cities. If someone hands you a nonce and 42 road numbers, it is indeed easy to verify, requiring negligible time and memory.

But finding such a cycle is no easy task. Note however, that a city that connects to one road only cannot be part of the solution, nor can that road. David Andersen pointed out that such dead-end roads can be repeatedly eliminated, using one bit of memory per road to remember if that road is useful, and two bits per city to count if there are zero, one, or multiple useful roads to that city.

This process of computing counts for cities, and marking roads that lead to a city with count one as not useful, is the essence of Cuckoo Cycle mining and accounts for about 98% of the effort. It results in billions of random global memory accesses for reading and writing the counters. Consequently, about 2/3 of the runtime is memory latency, making this a low-power algorithm that keeps computers running cool.

After a sufficient number of counting and marking rounds, so few useful roads remain that another algorithm, inspired by Cuckoo Hashing, can quickly identify cycles (re-using the memory for the no longer needed counters).

Cuckoo Cycle has some downsides as well. First of all, proofs are large and will roughly triple the size of block headers. Secondly, it is very slow, taking the better part of a minute on a high end CPU (or GPU, which offer roughly the same speed) to look for a cycle among a billion roads.

In order to give slower CPUs a (somewhat) fair chance to win, the block interval should be much longer than a single proof attempt, so the amount of memory Cuckoo Cycle can use is constrained by the choice of block interval length.

These seem like reasonable compromises for an instantly verifiable memory bound PoW that is unique in being dominated by latency rather than computation. In that sense, mining Cuckoo Cycle is a form of ASIC mining where DRAM chips serve the application of randomly reading and writing billions of bits.

When even phones charging overnight can mine without orders of magnitude loss in efficiency, not with a mindset of profitability but of playing the lottery, the mining hardware landscape will see vast expansion, benefiting adoption as well as decentralization.

Useless Darts Trivia

2014-12-22T00:00:00+00:00

Which scores are finishes?

One can throw 36, 40, or 50 plus any triple up to 120, and these numbers are 0, 1, and 2 modulo 3 respectively. In a picture:

           ... 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170
triple+36       *           *           *
triple+40           *           *           *           *
triple+50               *           *           *           *           *           *           *

finishes:  ... 150 151 152 153 154 155 156 157 158     160 161         164         167         170

How many possible 9-darter games are there?

This seems rather dificult to count until we start to distinguish cases based on final double and minimum of the first 8 darts. The 50,50 entry for instance is calculated as partitions of 501 - 50 - 8 * 50 = 51 into 0s, 1s, 4s, 7s, and 10s, with at least one 0:

(    8    )   (    8    )   (    8    )
(2 1 0 0 5) + (2 0 1 1 4) + (2 0 0 3 3) = 168 + 840 + 560 = 1568.


  \dbl     24    30    34    36    40    50
min\       --------------------------------
34                                       56
40                                      672
45                            8
48                           56
50                     56         672  1568
51                8         224
54               56         448
57          8    56          56

Giving a grand total of 3944 possible 9-darters, as confirmed in this report, which also states the number of essentially different solutions (as a multi-set of first 8 dart scores) as 22.

Note that a finishing double of e.g. 38 is not possible, as there is no way to partition 501-8*60-38 = -17 into the numbers -3, -6, -9, -10, -12, and -15.

In practice you’ll only see 9-darters starting with two 180s, leaving a 141 finish. The number of ways to finish 141 is calculated similarly:

  \dbl     24    30    34    36    40    50
min\       --------------------------------
                                      2
                                      2
                          2
                          2
                    2           2
              2           2
              2
        2

That’s 20 ways.

What is the most impressive 9-darter?

That would be throwing three 167 “finishes” in a row, repeating triple 20, triple 19, and bulls eye. The bulls eye is harder to hit than any triple, and a 9-darter can include at most three of them. I will likely never witness that in my lifetime, but then who could have imagined all of these incredible rarities?

John Tromp's Blog

The largest number representable in 64 bits

The largest number programmable in 64 bits

Ackerman considered unhelpful

Busy Beaver

How large is BB(6)?

Lambda Calculus

Proof of exceeding Graham’s Number

Lemma 1. J J = 2↑↑6 HH 2, where HH denotes H H

Proof:

Lemma 2. For k,n ≥ 2, k H 2 n > 3↑k(1+n)

Proof:

Lemma 3. For n ≥ 2, HH (HH n) > 3↑n3

Proof

Theorem: J J > Graham’s Number G(64), where G(n) = n (\n -> 3↑n3) 4

Proof:

Leaving Melo’s Number in the dust

Lemma 4. T T T = 2↑↑18 A 2 2 2 2 2 2 2 2 2 2

Proof: Let AA denote A A

Definition of Fast Growing Hierarchy

Lemma 5. For k≥0, n>=2, : k+1 A 2 [ωk α] n = [ωk (α+1)] n

Proof:

A Functional Busy Beaver

BB compared bit-by-bit to BBλ

But why Turing machines?

Interesting behaviour at small sizes

Ancient and fixed computational model

A Universal Busy Beaver

In conclusion

Nesting interpreters

Nesting interpreters

Universal Lambda Machine

Future work

References

Gaming the coordinates

The largest number representable in 64 bits

No primitives needed

Busy Beaver

Lambda Calculus

Proof of exceeding Graham’s Number

Definitions:

Lemmas:

Definitions:

Lemmas (assuming n ≥ 3):

A Functional Busy Beaver

But why Turing machines?

A Universal Busy Beaver

John adds blog

Flip Puzzles and Linear Algebra

SK numerals

Church Numerals

SK Combinatory Logic

A case for using soft total supply.

Beyond the Hashcash Proof-of-Work (there’s more to mining than hashing)

Useless Darts Trivia

Which scores are finishes?

How many possible 9-darter games are there?

What is the most impressive 9-darter?

Lemma 2. For k,n ≥ 2, k H 2 n > 3↑^k(1+n)

Lemma 3. For n ≥ 2, HH (HH n) > 3↑ⁿ3

Theorem: J J > Graham’s Number G(64), where G(n) = n (\n -> 3↑ⁿ3) 4

Lemma 5. For k≥0, n>=2, : k+1 A 2 [ω^k α] n = [ω^k (α+1)] n