smcracraft wrote:Bob, can you point me at a section of code in Crafty where the
old score is returned since the timeout was previously set?
My search is *ok* with fixed depth but abysmal with time. It is
in need of serious remediation.
When I back up something to the root, it is saved in the "triangular array" stuff. Once the abort flag is set, the triangular move array is never touched again. This leaves either the best score from the previous iteration if I have not yet had time to find a best move in this iteration, or else the best move from this iteration has already been backed up to ply 1 and that is what is actually played.
It isn't a matter of choosing what to do when time runs out, it is a matter of choosing to do nothing else that affects the backed up move and score once that happens... you just have to unwind the recursive calls to get back there.
Bob - thanks. This is the remark that fired the right neuron:
"When I back up something to the root, it is saved in the
"triangular array" stuff. Once the abort flag is set, the
triangular move array is never touched again. "
So I put this at my pv code in two places (in search() and
Code: Select all
pv[pg->ply][pg->ply] = move->m;
for (i = pg->ply + 1; i < pv_length[pg->ply + 1]; ++i)
pv[pg->ply][i] = pv[pg->ply + 1][i];
pv_length[pg->ply] = pv_length[pg->ply + 1];
The post-change testing (a few sample games and testsuite)
came out rather well. More testing follows...
Note to self: in the timeout() routine, the total nodes
searched is sampled at an occasional basis as to whether to do
the appropriate system call (infrequently) to avoid the system
overhead... of course