Author: Anthony Cozzie
Date: 06:36:39 11/04/03
Go up one level in this thread
On November 04, 2003 at 06:42:56, scott farrell wrote: >Consider the position below, just moving into the qSearch my engine tries the 2 >checks, and RxP. > >The checks lead to a qsearch for white that looses the rook. The RxP leads to a >qsearch for white of the promotion. > >Clearly it doesnt like any of these moves, so it just takes the stand-pat at the >node it is at. As such it is horizoning the fatalities in the qsearch. > >Is this correct? > >How many people use stand-pat ala crafty? Who uses what else? > >even though my engine has the pawn promotion in the qSearch, the stand-pat stops >it from playing it. > >A 1 depth search from this node, gives me 75 nodes, and the score drops by 5 for >black. > >One solution I can see is to staticly evaluate the rook as lost, so it wont >stand-pat at the node. My evaluate function doesnt really consider who's move it >is, to see the rook is undefended and under attack, and sideToMove is going to >allow its capture. I have some eval code for pinned pieces and enpris and the >like, but low values - it would seem to me here I could statically say the Rook >is lost. > >The only other solution I can think is to let the other side make its qsearch >moves anyway, sort of like null-move, and given they all fail-high for white, >dont allow the stand pat or something (sort of like dont allow stand-pat during >checks). > >[D] 8/PP4pk/4R2p/4p3/8/8/1K6/r7 b - - 0 61 I pretty much agree with Tord here. The problem is not Black's rook, it is the advanced white pawns. The rook is not lost - black can play Ra6 or Rh1 or something and save it. Two connected passed pawns on the 7th are at LEAST 1 rook imo. anthony
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.