Repository navigation
Repair one false doc sentence and three tests that could not fail - #257
Merged
Merged
Conversation
The module's own summary of what the table does not do yet opened by saying fail low nodes are not stored at all. They are: a node where no move raised alpha takes the else branch in alpha_beta and is written by record_ceiling as an upper bound, carrying the move that came closest. The rest of that sentence is still true and is kept. What has nowhere to go is a cutoff no move can be attributed to, which is what null move pruning or a static cutoff would want to record, and that is a different thing from a node whose moves all fell short. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every test in the transposition module worked at ply zero, where both halves of the mate score conversion are the identity, so not one of the twenty five could tell a working conversion from a broken one. Flipping the sign of score_from_tt leaves all of them passing and moves only the bench's node count, which says nothing about mates. This stores a mate nine plies down the line and reads it back two plies down, for a mate each way and for an ordinary score that no ply moves. It fails under either flip and under a dropped conversion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The exact count is a tripwire and not a gate, which this file already said. A change that means to move it updates the number, and the tripwire is rearmed one notch lower. Nothing in that stops the count walking down a few positions at a time until the suite says nothing, because each step is small and each is argued for on its own. Two things now stand beside the count. A floor at 210, held apart from it and moved only on its own account, which a build assertion keeps strictly under the snapshot so that lowering the snapshot past it fails the build rather than waiting for the suite job. The count has been 243, 241, 240, 237, 236, 229, 221, 226, 227, 228, 231 and 224 since the suite was first gated, and the largest single step in that list is eight, so the floor is not reached by an arm spending what an arm has ever spent. And an allowlist of losses taken on purpose, each naming the position, what bought it and the version its acceptance runs out at. It ships empty: the suite misses seventy six positions and none has been read one at a time, so anything here now would be a guess rather than a record. The next change that lowers the count is the first to write in it. The checks are what make writing in it mean something: an id that is not in the suite, an id twice, an entry with no reason, an entry whose version has passed, and an entry the suite has started finding again. The cheap checks run in the default suite, the one that needs the search runs with the suite itself, and a made up list carrying each fault once is what says they can fail. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The test named for the three instruments defaulting to their own rate could not fail on that half of its name. All three DEFAULT_EVERY constants are a thousand, so swapping two of them at the call site left the test passing and the whole workspace with it. Which of three equal constants a caller named is not checkable by value while they are equal, and the doc comment now says so. What is checkable is that sampling returns the rate it was handed rather than one of its own, so the three commands are handed three rates that differ and each has to come back with the one it was given. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Speed against
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four small items, none of which plays a game. The bench is unchanged at
3868987 and the tactical and strategic totals are unchanged, so nothing
here is a play change.
The transposition module said fail low nodes are not stored. They
are. A node where no move raised alpha takes the else branch in
alpha_betaandrecord_ceilingwrites it as an upper bound with themove that came closest on it. The rest of that sentence is true and is
kept: a cutoff no move can be attributed to, which is what null move
pruning or a static cutoff would want to record, still has nowhere to go
while an entry must name a play.
A floor under the tactical suite, held apart from the exact count.
The exact count is a tripwire. A change that means to move it updates the
number and the tripwire is rearmed one notch lower, and nothing in that
stops the count walking down a few positions at a time until the suite
says nothing. The floor is 210, kept strictly under the snapshot by a
build assertion so that lowering the snapshot past it fails the build
rather than waiting for the suite job. The count has been 243, 241, 240,
237, 236, 229, 221, 226, 227, 228, 231 and 224 since the suite was first
gated and the largest single step in that list is eight, so the floor is
not reached by an arm spending what an arm has ever spent.
Beside it, a list of losses taken on purpose, each naming the position,
what bought it and the version its acceptance runs out at. It ships
empty: the suite misses seventy six positions and none has been read one
at a time, so anything in it now would be a guess and not a record. The
next change that lowers the count is the first to write in it. What makes
writing in it mean something is the checking: an id not in the suite, an
id twice, an entry with no reason, an entry whose version has passed, and
an entry the suite has started finding again. A made up list carrying
each fault once is what says those checks can fail.
Transposition tests that leave ply zero. All twenty five ran at ply
zero, where both halves of the mate score conversion are the identity, so
not one of them could tell a working conversion from a broken one. The
new test stores a mate nine plies down and reads it back two plies down,
for a mate each way and for an ordinary score that no ply moves.
The instrument rate test could not fail on half its name. All three
DEFAULT_EVERYconstants are a thousand, so swapping two of them at thecall site left the test passing and the whole workspace with it. Which of
three equal constants a caller named is not checkable by value while they
are equal, and the doc comment now says so. What is checkable is that
samplingreturns the rate it was handed, so the three commands arehanded three rates that differ.
Each of the three test changes was checked by injecting the fault it is
meant to catch and watching it fail: the mate conversion flipped either
way,
samplingmade to ignore its argument, and the suite run droppedunder the floor, where the floor's message fires ahead of the snapshot's.
🤖 Generated with Claude Code