Author: GeoffW
Date: 10:02:14 10/18/04
Go up one level in this thread
Reading through my code, I have spotted another big bug which would be causing
problems in this area.
As I mentioned before I was only calculating a SEE value in my qsearch. I had
forgotten I have now got the following code in the qsearch function
/* are we in check? if so, we want to search deeper */
weAreInCheck = inCheck(sideToMove);
if (weAreInCheck)
generateAllMoves(); /* crude way of generating check evasions */
else
generateCaptures();
The generateCaptures() will calculate a SEE score for each move but the normal
generateAllMoves() will skip SEE calculation and have a 0 score for all moves.
So when I am in check the SEE code will badly screw up
The tidiest way to fix this is to enable SEE for normal search and qsearch, this
should remove some code duplication and solve the above problem.
The concern I have got is how badly it will slow my program down ?
I was clinging to the straw that my program plays weak chess but at least it
plays "fast weak" chess. I might have to abandon that way of looking at it.
So which of the 3 SEE tricks I described is valid to do in the normal search ?
1 ) SEE for Move ordering. Obviously yes this is sensible
2) SEE for pruning a capture move where SEE < 0. Nope, this should not be done
in normal search
3) SEE for pruning using material value and alpha value. This is probably OK
with a defined safety margin ?
Geoff
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.