The strengths and weaknesses of PVS

[bob]

Code: Select all

 
thisScore = -Search( depth - 1, -beta, -alpha, ply + 1, pvMove );
pvMove = FALSE;

Not sure what you are replying to.

How would you improve this textbook pseudocode?

Code: Select all

thisScore = -Search( depth - 1, -b, -alpha, ply + 1 ); 
if ( thisScore > alpha && thisScore < beta ) 
	thisScore = -Search( depth - 1, -beta, -alpha, ply + 1 );

Aha. your reply to his question followed _my_ post, which was what caused the confusion...

[bob]

Code: Select all

 
thisScore = -Search( depth - 1, -beta, -alpha, ply + 1, pvMove );
pvMove = FALSE;

Not sure what you are replying to.

But my point was, that in real game testing, when you don't have a hash move along the PV (which is not very common) it seems that most of the time a non-losing capture or a killer move is good enough, and those come with less effort than an IID search. In single positions, IID usually wins when it is used and doesn't hurt when it is not.

At a PV node you are not interested in a move that is "good enough" as searching the best move first will improve the bounds and make all the following searches more efficient.

Quite often there is not a "best move". There are several. But in any case, as I said, I removed IID from Crafty because it actually made it slightly stronger when testing on my cluster. That's my standard of measurement nowadays, how does something do in a large number of real games against different opponents using different starting positions.

[hgm]

Aha. your reply to his question followed _my_ post, which was what caused the confusion...

Well, this is how it works in flat view. They appear in chronological order. In threaded view my post was following the one it reacted to.