Leaving/Returning to Book Annoyance

[JVMerlino]

Newbie question of the week....

Now that I've implemented pondering into my engine, I'm having to deal with a fair amount of exceptions to my basic design, although nothing too horrendous to properly handle.

Early on I decided not to begin to ponder until I had left the opening book. I'm not even sure if any engine bothers to ponder while in book. I can't see how to do it (what is the expected reply?) or even the point, unless you already know for a certainty that you will be out of book on the next move (end of book line, max length of book -- does anybody check this, btw?).

The book that I implemented was ProDeo, thanks to Ed making the code available. Unfortunately I have learned after playing enough games that it is possible to leave book and then return to it. This is creating all sorts of nastiness when the engine is pondering because it left book earlier in the game.

The problem only happens if I get a match to the expected reply, of course. The engine continues thinking and makes its move, potentially not making the book move.

So, how to solve it? Here are the possibilities that I see:

1. Once I leave book, don't ever bother checking it again. (potentially lose data - what I've already implemented)
2. RE-check the book after every opponent move for the maximum length of the book. (always lose a little bit of time for those first 30 moves)
3. ???

Any thoughts would be appreciated....

jm

[Dann Corbit]

Newbie question of the week....

Now that I've implemented pondering into my engine, I'm having to deal with a fair amount of exceptions to my basic design, although nothing too horrendous to properly handle.

Early on I decided not to begin to ponder until I had left the opening book. I'm not even sure if any engine bothers to ponder while in book.

Some engines do a sanity check on the book move before playing it when using slow time control. If the sanity move score comes up bad then you can either check for alternates or search for a longer time or both.

For competitions, it is good to use a book where you have verified every move in the book by some means. Usually these competition books are very small (a few thousand key moves at most).

If you are pondering very early in the book I guess it will give you no benefit because the opponent is going to reply instantly if they have a book (and almost all programs do have a book). By the time your hash table is cleared you will be getting the opponent's reply to your book move so the search will have been totally fruitless.

I can't see how to do it (what is the expected reply?) or even the point, unless you already know for a certainty that you will be out of book on the next move (end of book line, max length of book -- does anybody check this, btw?).

The book that I implemented was ProDeo, thanks to Ed making the code available. Unfortunately I have learned after playing enough games that it is possible to leave book and then return to it. This is creating all sorts of nastiness when the engine is pondering because it left book earlier in the game.

The problem only happens if I get a match to the expected reply, of course. The engine continues thinking and makes its move, potentially not making the book move.

So, how to solve it? Here are the possibilities that I see:

1. Once I leave book, don't ever bother checking it again. (potentially lose data - what I've already implemented)
2. RE-check the book after every opponent move for the maximum length of the book. (always lose a little bit of time for those first 30 moves)
3. ???

Any thoughts would be appreciated....

jm

Once you start pondering, I think it is still OK to check the book.

Now, if the book move agrees with the ponder move you are in good shape. Just use the ponder move and pretend you did not even look at the book.

If the book move and the ponder move are different, then you have several choices:
1. Discard the book move and use the ponder move
2. Discard the ponder move and use the book move
3. Extend the thinking time to see if we get a match

If you have an excellent score then option 1 seems like a good choice.
If you have a bad score, then it seems like options 2 or 3 would be a good choice.

[jhaglund]

IMO, take the book move, if it matches a variation within the book.

The moves within the book should be taken. That is why the book was created in the first place.

Otherwise, fclose() book at first ended variation, ExitBook(), then start the Ponder().

Have some sort of null character to decide when the book line is done, and ponder should start.

Jumping I/O of the book is generally from a book creation problem. To me, pondering should start after the book exits.

If your program can tell if it's the last move in the book, I would think it'd be safe to start pondering on your opponent's time.

if(moves_in_variation <= 1), start ponder.

[MattieShoes]

My engine fills hash on opponent time -- no "expected reply" stuff, and it continues to use book if it's in book. Probably no real advantage except perhaps for first non-book move in a very fast time control game, when opp is human or a comp that drops out of book first. I mostly just did it because it was easy to do and shouldn't hurt things.

Moving back into book is probably okay as long as rep draws are handled right. Otherwise I've seen engines get rep draws in the first 15 moves popping into and back out of book.

[bob]

Newbie question of the week....

Now that I've implemented pondering into my engine, I'm having to deal with a fair amount of exceptions to my basic design, although nothing too horrendous to properly handle.

Early on I decided not to begin to ponder until I had left the opening book. I'm not even sure if any engine bothers to ponder while in book. I can't see how to do it (what is the expected reply?) or even the point, unless you already know for a certainty that you will be out of book on the next move (end of book line, max length of book -- does anybody check this, btw?).

In Crafty, the "search" has two parts. Part 1 is a book lookup. That code returns two moves, the first is the move the program should play according to the book, the second is the expected book reply to that move (the move to ponder). If that fails, the second part of tthe search is a normal alpha/beta search that returns a PV and score.

Since my book code returns a PV of length 2 (the book move and the book reply) I treat both results (book or search) the same. I get a PV from both, which has a move to play and a move to ponder. On occasion either can return a PV without the move to ponder. In the case of the book, that just means that the book ends after the move for the program, with no opponent move supplied. A search can also produce this result when you get a fail high and don't have enough time to get a real score back. There are ways to choose a move to ponder if you don't have one. We can discuss that if you want, although it is not related to your current question.

The point for pondering on a book move is simple. What do you do at the end of the book line? You just sit and wait until your opponent moves, only to discover you have no book move to play so you start a normal search. Why not find the opponent's book move and ponder that? If you find a book move to play, you can sit or do other things. If you do not find a book move when you ponder his book move, you can start a normal search and save some time.

The book that I implemented was ProDeo, thanks to Ed making the code available. Unfortunately I have learned after playing enough games that it is possible to leave book and then return to it. This is creating all sorts of nastiness when the engine is pondering because it left book earlier in the game.

The problem only happens if I get a match to the expected reply, of course. The engine continues thinking and makes its move, potentially not making the book move.

I have a function, Iterate(), that is called to obtain the next move. It first tries the book, if that fails it does a normal search. This solves the issue completely.

So, how to solve it? Here are the possibilities that I see:

1. Once I leave book, don't ever bother checking it again. (potentially lose data - what I've already implemented)
2. RE-check the book after every opponent move for the maximum length of the book. (always lose a little bit of time for those first 30 moves)
3. ???

Any thoughts would be appreciated....

jm

[bob]

My engine fills hash on opponent time -- no "expected reply" stuff, and it continues to use book if it's in book. Probably no real advantage except perhaps for first non-book move in a very fast time control game, when opp is human or a comp that drops out of book first. I mostly just did it because it was easy to do and shouldn't hurt things.

Moving back into book is probably okay as long as rep draws are handled right. Otherwise I've seen engines get rep draws in the first 15 moves popping into and back out of book.

Another idea I use, which came from Murray Campbell years ago, is to find the set of known book moves for my opponent, and remove this set from the set of legal moves he can play. I then do a short search on this remaining set, to find the "best" non-book move I can find. I then ponder this move wile waiting on my opponent. The idea is that if he plays a known book move, I have a quick response in the book. If he is now out of book, he will likely play the move my search suggests and I will already be pondering that move.

In Crafty, you turn this on by entering "mode tournament" or else putting that in the crafty.rc/.craftyrc file.

[JVMerlino]

Thanks, Dann. Great suggestions.

Not sure yet what I'm going to implement. For now, I've just decided to take a book move when I find it in all cases, on the assumption that the ProDeo book has been so thoroughly scoured by Jeroen Noomen that the chances of a bad book move could very well be zero.

Thanks again,
jm

[JVMerlino]

IMO, take the book move, if it matches a variation within the book.

The moves within the book should be taken. That is why the book was created in the first place.

Otherwise, fclose() book at first ended variation, ExitBook(), then start the Ponder().

Have some sort of null character to decide when the book line is done, and ponder should start.

Jumping I/O of the book is generally from a book creation problem. To me, pondering should start after the book exits.

If your program can tell if it's the last move in the book, I would think it'd be safe to start pondering on your opponent's time.

if(moves_in_variation <= 1), start ponder.

Hi Joshua,

With the ProDeo book, it is possible to tell if a line has ended...sort of. But there is no way to determine if it is possible to go back into book later on.

Thanks for the reply,
jm

[JVMerlino]

Moving back into book is probably okay as long as rep draws are handled right. Otherwise I've seen engines get rep draws in the first 15 moves popping into and back out of book.

That's an interesting thought. It hasn't happened yet in the hundreds of games I've tested, but I think it is theoretically possible given that the book works off of FEN positions rather than a move list.

Thanks for that -- I'll keep it in mind.

jm

[JVMerlino]

[quote="bobAnother idea I use, which came from Murray Campbell years ago, is to find the set of known book moves for my opponent, and remove this set from the set of legal moves he can play. I then do a short search on this remaining set, to find the "best" non-book move I can find. I then ponder this move wile waiting on my opponent. The idea is that if he plays a known book move, I have a quick response in the book. If he is now out of book, he will likely play the move my search suggests and I will already be pondering that move.

In Crafty, you turn this on by entering "mode tournament" or else putting that in the crafty.rc/.craftyrc file.[/quote]

Sounds like a great idea, although isn't the data set huge? Or can Crafty only "prepare" for one opponent per run?

jm