endgame table generation

Discussion of chess software programming and technical issues.

Moderator: Ras

syzygy
Posts: 5982
Joined: Tue Feb 28, 2012 11:56 pm

Re: endgame table generation

Post by syzygy »

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-L327

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;
}
This 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.
I just noticed that KQPvKR.rtbz went from 6202512 bytes to 4925776 bytes with this fixed, a 20.6% reduction in size.
On the other hand, KQPvKQ.rtbz goes from 16695824 to 16616272, which is less than a 0.5% reduction.