Author: Richard Pijl
Date: 01:26:10 04/14/04
Go up one level in this thread
On April 14, 2004 at 03:49:06, Dann Corbit wrote:
>On April 14, 2004 at 03:46:08, Richard Pijl wrote:
>
>>On April 14, 2004 at 03:30:22, Dann Corbit wrote:
>>
>>>I decided to toss an MTD(f) search into TSCP, and I've got something wrong, but
>>>I can't quite see what it is.
>>
>>MTD(f) requires a transposition hashtable and a fail-soft search to function
>>properly. Did you add/change that too?
>
>With hash table, I get this behavior:
>post
>sd 99
>st 99
>go
>Depth Eval Time Nodes PV
>1 48 0 172
>2 0 20 2224 d2d3
>3 35 40 4858
>4 5 321 41505 e2e3
>5 35 711 93485
>6 13 5438 780563 d2d4
>7 30 11878 1638246
>8 18 81509 11563089 e2e4
>move e2e4
>
I guess you're referring to the empty PV lines?
That's normal, as TSCP doesn't store the PV on a fail high/low. As TSCP is
searching with an open window in the root, you will always have a PV. But with
MTD(f) you're searching with null-windows, so you won't have a PV.
Did you change stuff in search to deal with pv with fail high/lows?
In your code below, you're setting a move in the pv array, but that move is
basically random:
if (f < beta)
greatest = f;
else {
int j;
smallest = f; /* performs a cut-off */
if (smallest >= greatest) {
pv[ply][ply] = gen_dat[depth].m;
for (j = ply + 1; j < pv_length[ply + 1]; ++j)
pv[ply][j] = pv[ply + 1][j];
pv_length[ply] = pv_length[ply + 1];
}
}
gen_dat[depth].m is a generated move in the movelist, but it is not the
bestmove. It isn't even the first move in the move list as depth is increased on
every iteration.
bye,
Richard.
>>As the same position is searched again and again with a different null-window,
>>the transposition table will contain many of the positions to search with a
>>bound yielding many cuts.
>>
>>Richard.
This page took 0.01 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.