Monte-Carlo methods are known to intensively create nodes and in our
case each leaf of the tree stores a board. However, for this use case,
we don't need a full board object that also contains game information.
This patch adds a `clone_cleared()` method that return a clone without
game information and uses it when constructing the tree.
It allows the ChessEngine much more possibility before getting out of
memory.
This prevents us from needing a sv suffix, and potentially reduces the
need to run generic code for a single character (as contains,
starts_with, ends_with etc. for a char will be just a length and
equality check).
No functional changes.
Each of these strings would previously rely on StringView's char const*
constructor overload, which would call __builtin_strlen on the string.
Since we now have operator ""sv, we can replace these with much simpler
versions. This opens the door to being able to remove
StringView(char const*).
No functional changes.
One of the conditions for legal move is that the target square is not
occupied by a piece of the same color as the moving piece.
Instead of checking this for each piece separately at the end, we can
check this at the beginning and avoid more expensive checks.
In cases with ambiguous captures involving pawns (where multiple pieces
could have made the capture), we were exporting invalid syntax for
the move:
`1. e4 e5 2. Bb5 c6 3. Bxc6 ddxc6`
Move 3 should be `Bxc6 dxc6`, but we were duplicating the d on the pawn
move.
Make everything signed so that we don't have to deal with silly casting
issues thoughout the Chess code. I am unsure if this affects the chess
AI negatively, it seems just as "intelligent" before and after this
change :^)
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
