oh no, 8 hours i need to devlog more holy moly
from last devlog, i kinda found a solution to the fail-soft problem?
Most engine’s LMR implementations will re-search twice if the previous search went over alpha (lower bound). The first search has reduced depth AND a null-window around alpha (search window of 1 centipawn; searches faster, but can only tell the direction of the true search result); if this is over alpha, it’ll re-search with full depth; if this is again over alpha, it’ll re-search with full depth and full bounds. My engine was skipping the middle step and jumping from reduced depth + null window -> full depth + full bounds. Apparently this is an accepted method and it was working fine compared to the other version, EXCEPT once I switched to fail-soft on beta.

in other news, I added:

• aspiration windows (75 elo): the initial search is normally unbounded, but aspiration windows try to clamp the search around a “guess” based on the previous depth of iterative deepening, and widen if it fails high or low. it did almost nothing before, and randomly became really good. don’t ask me why.
• razoring (22 elo): prunes a node if quiescence search says it’s too far below alpha. I already had it in a previous version and brought it over to the search rewrite. pretty simple, smallish elo boost.
• late move pruning (39 elo): prunes the latter part of move list; moves are sorted by how good they’re predicted to be, so latter moves are usually pretty garbage
• fixes (23 elo): small logic changes to LMR and LMP. don’t know how they didn’t lose more elo, the LMR bug was kinda bad.
• separate PV tracking: the PV (principal variation, the best moves for each player as calculated by the engine) was previously tracked by the transposition table, but that meant i didn’t have a lot of flexibility with the replacement strategy for the table, lest it wipe an important PV entry. tracking it separately lets me fiddle with the replacement strategy more, although I haven’t actually found one better than what I have now

here’s a graph generated from a google sheet with 100k rows (!?). it’s a histogram of every time a move was marked as “currently the best”, indexed by entry. ideally, it’d be all 0, meaning the best move was searched first every time, meaning there was basically no wasted effort.