Author: Robert Hyatt
Date: 12:00:03 01/07/02
Go up one level in this thread
On January 07, 2002 at 11:40:10, David Rasmussen wrote: >On January 07, 2002 at 10:03:41, David Rasmussen wrote: > >>In SEE, the king should of course be the last to capture, as no piece can >>capture the king. But the king should also have some large value to indicate a >>winning capture for the opposing side. In a position such as this: >> >>[D]2rqkb1r/p1pnpppp/3p3n/3B4/2BPP3/1QP5/PP3PPP/RN2K1NR w KQk - 0 1 >> >>The captures on f7 will be bishop, knight, bishop, king, queen. >> >>In my program in general, the king has a value of 0, as the kings value has >>never been used for anything before. For SEE, the value has to be used, however. >>To be safe, I would really want to give my king the value of 9 queens plus the >>value 2 knights, bishops and rooks, but then the value of a position with these >>pieces, and only one king on the opposing side will be to big to hold in my >>current Score type, as I am only willing to spend so many bits of scores, so it >>doesn't use up to much space in a hashentry. Actually, writing this, I will >>think out loud that there will always be two kings on the board, and as such, >>the values of the kings will balance out, which means it doesn't matter. Instead >>of not sending this post, I will send it anyway, as a windows into my idiotic >>brain. >> >>/David > >I guess I was a little to quick to send that message. Because it isn't just >enough to have a large value for the king. That will make the SEE indicate that >a capture sequence that ends with a capture by the opposing king, is a really >good one. So what we really want, is to back up two captures, if we capture a >king. So in the above position, the SEE would say "Wait a minute, I have >captured his king, which means that my move will never happen and his move was >illegal. The expected gain from the capture is therefore the gain from to moves >ago, which is 1. > >What do you do in such cases? Crafty doesn't do this, as far as I can see. It >just sorts captures that end with a king capture, highly. I know the SEE of most >programs, is not very accurate, and is not meant to be, because it is used for >move ordering "only". For example, I think many SEE's don't check whether moves >leave the king en prise etc., but an inaccuracy such as the one I decsribe, >seems to large, considering how easily it is fixed. > >/David The _only_ time Crafty's SEE says that capturing a king is permissable is the case where you pass it a square that has a king sitting on it and the king is "in check" (which happens with pseudo-legal moves in the q-search). It will _not_ return a huge score (nor a very negative score) when a king capture happens _in_ the sequence of captures being SEE evaluated. The minimax procedure used in the SEE scoring simply will not let that happen. I'm not sure where all this confusion is coming from, but you will _never_ see a SEE score that suggests that a king will be won or lost except in the first case given above. Otherwise it works perfectly. And in the first case above, I _want_ the king capture to be ordered first anyway as that will cause the real search to say "hey, last move was illegal, bail out". I want that to happen _first_ not after a couple of captures have been searched already, which will save some nodes...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.