It seems like it’s partially based on LeanChess [1], which is 288 bytes long. I’d be curious to know whether this program was AI-assisted or written entirely from scratch, since Lean Chess was written at a time predating the era of LLMs.

Another thing that amuses me is that these tiny programs often claim to be “complete” chess engines while not actually implementing all the rules. This one doesn’t appear to support en passant, and likely doesn't have pawn promotion either.

If you’re allowed to arbitrarily redefine the scope of chess, then code size stops being as impressive a metric.

[1] - https://leanchess.github.io

▲

ekelsen 3 days ago | parent [-]

Yeah, I don't understand why the metric isn't "complete chess engine that achieves X ELO" in yyy bytes or something.

Instead it seems to have been "minimal thing that kinda looks like chess in yyy bytes"

▲

applfanboysbgon 3 days ago | parent | next [-]

> X ELO in yyy bytes

Because then you're measuring on two axes. Which is better, 1500 elo in 300 bytes or 1550 elo in 310 bytes?

For a byte count comparison to make much sense, the program really ought to have a static target criteria.

	▲	ekelsen 3 days ago \| parent \| next [-]
		I used a placeholder for X ELO, but my point was the community should pick one value that makes sense and then not change it.
	▲	noiv 3 days ago \| parent \| prev [-]
		Interesting would be how much bytes improve by 100 ELO?

▲

taftster 3 days ago | parent | prev [-]

I'd suggest just ensuring that the entire rules of chess are first evaluated or supported in a chess program, before worrying about ELO rating, etc.