Skip to content

[1d-chess] Make AI force a 6-move mate instead of a 5-move#9

Open
msullivan wants to merge 1 commit intoRowan441:masterfrom
msullivan:search-fix
Open

[1d-chess] Make AI force a 6-move mate instead of a 5-move#9
msullivan wants to merge 1 commit intoRowan441:masterfrom
msullivan:search-fix

Conversation

@msullivan
Copy link
Copy Markdown

@msullivan msullivan commented Apr 12, 2026

I saw this on HN and after flailing around trying to win it, got
annoyed and wrote (by hand, out of some potentially misplaced pride) a
solver to find the winning line, and discovered that the AI's response
was suboptimal and led to a 5-move mate instead of the 6-move one the
searcher found.

I looked at the code and noticed that the search didn't include depth
in the score, and so wouldn't try to prolong the game as long as
possible. The game is saved from being trivial by its move-ordering:
it searches captures before other moves, and prefers the last
"optimal" move it finds. If it searched captures last, then it would
respond to N3 with R3, followed by a mate in 2 more turns.
(This was the most interesting question here, to me, since the game
still plays quite well despite an issue that would have been fatal to it
without the move ordering being the way it is!)

Fixes:

  • Include the depth in the computed score, so that black tries to prolong
    the game even in a losing position.
  • Remove early-returns and state dependent code that got in the way of
    maximizing length.
  • Fix the beta calculation for alpha-beta pruning. Not sure if this
    matters at all.

Code changes are from Opus 4.6 but I've reviewed them and think they
are legit. This message actually written by a human.

I saw this on HN and after flailing around trying to win it, got
annoyed and wrote (by hand, out of some potentially misplaced pride) a
solver to find the winning line, and discovered that the AI's response
was suboptimal and led to a 5-move mate instead of the 6-move one the
searcher found.

I looked at the code and noticed that the search didn't include depth
in the score, and so wouldn't try to prolong the game as long as
possible. The game is saved from being trivial by its move-ordering:
it searches captures before other moves, and prefers the last
"optimal" move it finds. If it searched captures last, then it would
respond to N3 with R3, followed by a mate in 2 more turns..

Fixes:
- Include the depth in the computed score, so that black tries to prolong
  the game even in a losing position.
- Remove early-returns and state dependent code that got in the way of
  maximizing length.
- Fix the beta calculation for alpha-beta pruning. Not sure if this
  matters at all.

Code changes are from Opus 4.6 but I've reviewed them and think they
are legit. This message actually written by a human.
@msullivan
Copy link
Copy Markdown
Author

Oh I somehow missed noticing there was an issue filed that you had responded to already #6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant