I just noticed that KQPvKR.rtbz went from 6202512 bytes to 4925776 bytes with this fixed, a 20.6% reduction in size.syzygy wrote: ↑Wed May 13, 2026 3:52 pmRecently I found a small bug in my generator. I think it was here:
https://github.com/syzygy1/tb/blob/0bb8 ... #L321-L327This overwrites PAWN_WIN with WIN_IN_ONE. So a position with both a winning pawn move and a mating move is encoded as win-in-1, whereas it "should" be encoded as don't care. This does not affect correctness (otherwise it would have been found earlier) and it doesn't seem to have a significant impact on compression ratio (but I did not test on many tables). But the correct test is table[idx2] > WIN_IN_ONE.Code: Select all
MARK(mark_win_in_1) { MARK_BEGIN; if (table[idx2] != ILLEGAL && table[idx2] != CAPT_WIN) table[idx2] = WIN_IN_ONE; MARK_END; }
On the other hand, KQPvKQ.rtbz goes from 16695824 to 16616272, which is less than a 0.5% reduction.