I have written a simple chess engine, with hashing, and yes, mate scores work correctly
When a score is returned that shows the computer has a forced mate against the human, I have code to reduce the size of the tree by 2 plies. For example, if the depth started at 9 plies but it found a forced mating line against the human on ply 5 (mate in 3), then the tree can shrink to 3 plies on its next search, since mate in 2 is the only better move.
That all works fine for me. My question is regarding free depth that hashing gives you. For example, it is perfectly possible for a 5 ply search to return a score showing it knows there is a forced mate in 4 (on ply 7), because of hashing. I should not shrink the tree in that case - keep it at 5 plies, since the next move would be mate on ply 5. But what if a 6 ply tree finds a mate on ply 9? Should I keep it at 6? Or *grow* it to 7, since the next move has to find mate on the 7th ply. I can't guarantee the free depth will work twice in a row..., right?
AndrewShort wrote:I have written a simple chess engine, with hashing, and yes, mate scores work correctly
When a score is returned that shows the computer has a forced mate against the human, I have code to reduce the size of the tree by 2 plies. For example, if the depth started at 9 plies but it found a forced mating line against the human on ply 5 (mate in 3), then the tree can shrink to 3 plies on its next search, since mate in 2 is the only better move.
That all works fine for me. My question is regarding free depth that hashing gives you. For example, it is perfectly possible for a 5 ply search to return a score showing it knows there is a forced mate in 4 (on ply 7), because of hashing. I should not shrink the tree in that case - keep it at 5 plies, since the next move would be mate on ply 5. But what if a 6 ply tree finds a mate on ply 9? Should I keep it at 6? Or *grow* it to 7, since the next move has to find mate on the 7th ply. I can't guarantee the free depth will work twice in a row..., right?
Since it only kicks in when a checkmate is found at the root, how much do you think this will save you in a game ? Worth the trouble ?
AndrewShort wrote:I have written a simple chess engine, with hashing, and yes, mate scores work correctly
When a score is returned that shows the computer has a forced mate against the human, I have code to reduce the size of the tree by 2 plies. For example, if the depth started at 9 plies but it found a forced mating line against the human on ply 5 (mate in 3), then the tree can shrink to 3 plies on its next search, since mate in 2 is the only better move.
That all works fine for me. My question is regarding free depth that hashing gives you. For example, it is perfectly possible for a 5 ply search to return a score showing it knows there is a forced mate in 4 (on ply 7), because of hashing. I should not shrink the tree in that case - keep it at 5 plies, since the next move would be mate on ply 5. But what if a 6 ply tree finds a mate on ply 9? Should I keep it at 6? Or *grow* it to 7, since the next move has to find mate on the 7th ply. I can't guarantee the free depth will work twice in a row..., right?
I'm not sure if this will help you, but I would continue searching for better (shorter) mates after I've already found mate, using iterative deepening.
If you have search extensions (for example, on checks) then keep in mind that the first mate you find won't necessarily be the shortest mate possible. (A deeper search can sometimes find a shorter mate.)
Of course, the exceptions are that a mate-in-1 is always the shortest mate possible, and a mate-in-2 is the shortest possible if you've already determined that there cannot be a mate-in-1, and so on...
AndrewShort wrote:... But what if a 6 ply tree finds a mate on ply 9? Should I keep it at 6? Or *grow* it to 7, since the next move has to find mate on the 7th ply. I can't guarantee the free depth will work twice in a row..., right?
It's a mate in 9 (plies) wherever it comes from, the fact that you got that score from the hash does not change anything, you still want to find a mate in less than 9 plies.
I'm not sure I understand your tree shrinking. I find it simpler to determine a maximum depth search once you have a mate score than to do relative depth adjustment. In your example you got a mate in 9 at ply 6, this mean that you can go up to depth 8, you'll never find somethnig better at depth 9.
In RomiChess I have a variable for 'quickest mate' that is initialized to infinity. When on the next search I find a mate shorter than what that variable contains that depth is stored and the search is stopped.
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
I forgot to indicate in my original post that I have not gotten around to implementing Iterative Deepening yet. My simple engine lets you pick a "level", which ends up being the depth to which the engine searches (I don't have QS or SEE yet, either).
Having said that, it makes a lot of sense for me to shrink the tree if the computer finds a forced mating line agaisnt the human. The shrinking can be dramatic. If on a 9 ply search it all of a sudden sees mate in 4 (mate on the 7th ply) against the human, the tree can be shrunk to 5 plies - that's a reducton of 4 plies! The end result is that after the first move of a forced mating line against the human, the computer finishes the mating line instantly.
I suspect when I implement Iterative Deepening, that this all changes, simply because if the engine sees the mate on ply 7, it can stop the iterations early (before some max depth or max time is reached). On its next move in the mating line, it will continue to stop early, since it keeps finding the shorter and shorter mates.
ust postpone this until after you have implemented Iterative Deepening. Because you got to have that anyway, and once you have it wou would want to solve this in a different way.
In Joker I continue ID until the reported mate is within the horizon. In pracice this works quite well. (Although it is not really 100% guaranteed that there is no faster mate, because of the reductions I do: a 9-ply search might search some lines only to 7 or 5 ply.)
