[danieltanfh95]

This isn’t about whether the writer uses LLM or not at all, nor is it about respect. The core novelty it tries to introduce is not hard to understand (even if it is not really that novel). If you don’t want to spend time thinking about what interesting idea it is exploring, that is fine, but pretending or insinuating that it is a LLM problem is just lazy.

[mccoyb]

Explain away then my friend: surely your clear explanation will benefit many other readers who came away with similar confusion?

[danieltanfh95]

Exploring if it makes sense to use maths (or, to be precise, this particular construction) to drive content addressable content + other exploration around the memory space. IMO, no.

https://news.ycombinator.com/item?id=48436337

[Retr0id]

What is the core novelty?

[danieltanfh95]

Exploring if it makes sense to use maths (or, to be precise, this particular construction) to drive content addressable content + other exploration around the memory space. IMO, no.

https://news.ycombinator.com/item?id=48436337

[Retr0id]

I have a strong understanding of content addressing, memory allocation, data structures, and a superficial understanding of lattices. It is not clear how one has anything to do with the other. If there is any meaningful link or benefit, it has not been explained.

Perhaps some magical insight is waiting for me if I understand the Leech lattice better, but given PhD category theorists are also scratching their heads I think I'll pass https://news.ycombinator.com/item?id=48436251

[amenn]

Still writing the docs. Content addressing is the mechanism, that is: same content lands in the same slot, equality is a handle compare. The allocator is provably extensional so distinct content never aliases even though the hash itself can collide. The Leech part: the heap is sized to the lattice's 196,560 minimal vectors, the coordinate-to-slot map is a collision-free perfect hash built from the Conway group's mm_op tables, and that fixed universe is what makes sets into 196,560-bit bitmaps with O(1) membership and bitwise ops.

[Retr0id]

I understand that you can hash any object into a 196,560-slot space (that's how regular hash tables work), but I'm not sure why you'd want to do that. Regular hash tables can be resized when they get full (or less-full), yours cannot. How is this any different from a hash table with a fixed capacity of 196,560 entries?

"provably extensional" is not an established term in this context and communicates nothing about the design. I simply do not believe that this design doesn't have trivial collision issues, or that it makes efficient use of memory.

[jrmg]

Are you saying that two distinct pieces of content can never collide? That seems obviously incorrect.

For example, take the integers 0 - 196,561, and put them into your lattice-based map. Something’s got to give. There are only 196,560 containers in the map (right?)

[Retr0id]

It's just a regular hash table with linear probing https://github.com/yon-language/yon/blob/aa4617ced3abc92ac53...

The only relation to the Leech group appears to be the number of slots.

When a table gets full they allocate a second one, and so on, up until 256 tables when allocations start silently failing (after exactly 50319104 allocations).

[GreenSalem]

It is not exploring anything.

It is bluntly stating nonsense, while misunderstating the basics of Leech lattices and the Yoneda lemma.

A 12 year old with a LLM could do better.