This is a great introduction to that most ancient and elegant model of computation. But I was a little sad to read:

> One can represent natural numbers in a simple way, as follows:

> Definition (ordered tuples, natural numbers) The ordered tuple ⟨a0 , … an⟩ of λ-terms is defined as λx [x a0 … an]. One then defines the λ -term ┌ n ┐ corresponding to the natural number n as: ┌ 0 ┐ = I and, for every k, ┌ k + 1 ┐ = ⟨F, ┌ k ┐⟩

which is a rather convoluted and impractical way to represent natural numbers compared to the Church numerals Cn which iterate a given function n times on a giving argument.

There are cases where it makes sense to use tuples to represent natural numbers, namely to simplify the definition of predecessor, subtraction, and comparison. But that uses 1-tuples rather than 2-tuples [1].

Replacing Church numerals by tuple numerals allowed a googologically VERY large number (based on the so-called Bashicu Matrix System) to be expressed in only 350 bits rather than 404 bits. [2]

[1] https://github.com/tromp/AIT/blob/master/numerals/tuple_nume...

[2] https://github.com/tromp/AIT/blob/master/fast_growing_and_co...

How is a 1-tuple different from a non-tuple?

According to the definition of a tuple above, a 1-tuple <a> is λx. x a.

So <a> is a function that applies its argument to a.

Unfortunately no mention of the most important spec, particularly for AI: the memory bandwidth.

"high bandwidth memory" aka HBM is mentioned.

It's not specific enough, but implies the bandwidth will be high (:

The Rat of the Deal...

They didn't. You confused reports that a majority of parliament wants to do so.

On top, the government warned that it's legally improbable.

Typical right wing rethoric, abusing the parliament process for campaign material.

While bitcoin script is a stack language, it doesn't really qualify as Forth as it doesn't allow you to define any new words.

Bond yield is the return an investor will realize on a bond, so driving down prices decreases yields. Sure, it can increase the absolute value of yield as it heads into the negative...

No, because "yield" almost always refers to yield to maturity.

I wanted to check the prime factors of 1966 the other day so I googled it and it led me to https://brightchamps.com/en-us/math/numbers/factors-of-1966 , a site that seems focussed on number facts. It confidently states that prime factors of 1966 are 2, 3, 11, and 17. For fun I tried to multiply these numbers back in my head and concluded there's no way that 6 * 187 could reach 1966.

That's when I realized this site was making heavy use of AI. Sadly, lots of people are going to trust but not verify...

This is also very wrong

> A factor of 1966 is a number that divides the number without remainder.

>The factors of 1966 are 1, 2, 3, 6, 11, 17, 22, 33, 34, 51, 66, 102, 187, 374, 589, 1178, 1966.

If I google for the factors of 1966 the Google AI gives the same wrong factors.

They're talking about prime factors, not that it changes much.

The site also lists the factors and beside 1,2 and 1966 they are all wrong.

Google harvests its result from the same page

> The factors of 1966 are 1, 2, 3, 6, 11, 17, 22, 33, 34, 51, 66, 102, 187, 374, 589, 1178, and 1966. These are the whole numbers that divide 1966 evenly, leaving no remainder.

Watch the 2024 finals in action: https://www.youtube.com/watch?v=Zafp5yTKCyA&t=225s

Hard to break the cycle with the broken first-past-the-post voting system.

Wolfram's exploration of longest lifetimes of lambda terms of a given size is carried out more systematically in my functional busy beaver https://oeis.org/A333479

Would love to read a HN-tailored blog post of your work or an overview of the binary lambda calculus if you ever have the time btw

A walkthrough would be nice, but he's got a lot of understandable material linked on that page. For example, here's an overview of the binary lambda calculus: https://tromp.github.io/cl/Binary_lambda_calculus.html

And here's a readable and fascinating post on "the largest number that's representable in 64 bits": https://tromp.github.io/blog/2023/11/24/largest-number.

If you go through these and find some interesting things, it'd be worth posting to HN.

https://tromp.github.io/cl/cl.html has many links to BLC materials, like my LispNYC video talk.

Is this easier to analyze than Turing Machine based Busy Beaver?

The first 5 values are FAR easier to determine, since there's only 1 lambda term of at most 5 bits:-)

And the next few unknown values, BBλ(37).. BBλ(39) will be easier to determine too since the search space is smaller and no so-called cryptids have been identified yet (terms whose halting behaviour is closely related to unsolved math problems).

But if the effort that is being applied to researching BB(6) and BB(7), is applied to researching BBλ(37) and beyond, then we expect to run into similar difficulties of having more and more unsolved terms which do not lead to a normal form in any reasonable number of steps and also defy known techniques for proving them to lack a normal form.

There's some hope though that we'll be able to identify BBλ(49) before identifying BB(7). And while the former is known to exceed Graham's Number, the latter is only conjectured to do so, and I made a large bet with the people conjecturing it saying it won't be proven within 10 years.

Very interesting, thanks!