rabbitoid:

The total number of positions we resolve will always be less than the entire state space. For example, in a pawnless database, you only have to place one king on 20 of the 80 squares. This is because any position can be "rotated" to get the king onto one of those squares, either by a horizontal flip, vertical flip, or diagonal flip. You rotate the other pieces along with it, and where they end up is the position you look up in the database. Then you likewise translate that move to the unrotated move on the board.

Once you have one pawn on the board, you lose this 75% reduction symmetry. You can still cut the db in half, by constraining the pawn to the files a through e. If it is on files f through j, you can just flip the position horizontally, and look up that result.

Our tables are truly "distance to mate" and not "distance to conversion". That means the first thing we do in any new database is first generate ALL cpatures into smaller databases, and ADD those "distance to mate" to our positions prior to the capture.

This way, every move in the database is the quickest way to get to the final mate, and not just the quickest way to get to the next subdatabase.

I have seen such "distance to conversion" database play extremely strange moves at times, especially when each side has a pawn.

There could be a mate in N moves, but the pawn can promote in N - k, so the program would make the pawn promoting move (faster conversion than a mate in N), which could allow the game to drag on for many, many more moves.