Here is what I do more precisely. Suppose I complete a 30 ply search and make a move. I chop the first two moves off of this PV, since the first was played and the second is the opponent's expected reply. I save this move to ponder, and I make the remaining 28 ply PV the "current PV".elcabesa wrote:this is exactly what I was thinking to do.bob wrote: I always use the PV from the previous search. I take the second move and ponder that. I take the remainder of this PV and stuff it into the hash table to be sure those moves are searched first. I also use the previous value to set the aspiration window for this new search.
let me explain:
1) consider a game without permanent brain or ponder
2) each time it's my turn to think, let's see whether or not we are in the same game of the previous search and whether we have a ponder hit.
3) in case of ponder hit use the info of the previous search to enanche the new one
3.1) start searching with the old PV
3.2) start searching with the old aspiration window
3.3) start the search with a depth of the old PV-2 or something similar.
the point 3.3 is giving me lot's of problem because sometimes starting from a very high deep it wasn't able to complete an iteration and the new PV searched is void and the engine reports an empty PV, it could have returned data from the old PV but up to now it doesn't do that.
I'll try experimenting with this
Now, since I have a PV for a 28 ply search, I start the search (pondering on the opponent's expected move) at depth=29, since the 28 ply search has already been completed and the useful info for ordering is still in the hash table.
I've done this since the 70's...
But if you stuff the current move history into crafty, as some interfaces do, it wrecks that and I have to start over from scratch.