Author: Henk Bossinade
Date: 11:55:53 10/18/04
Go up one level in this thread
On October 18, 2004 at 13:02:14, GeoffW wrote: >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 ? I doubt the last point. You can use futility pruning but that usually doesn't rely on SEE as far as I know. > > Geoff
This page took 0 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.