Author: Volker Böhm
Date: 14:05:31 08/04/04
Go up one level in this thread
On August 04, 2004 at 16:46:51, José Carlos wrote: >On August 04, 2004 at 16:04:00, Volker Böhm wrote: > >>Hi, >> >>Spike does worse when cutting from see in quiescense too. Don´t know why, but I >>haven´t found a bug in see. >> >>Greetings Volker > > You both cut only captures with negative SEE score, right? And only in >quiesce, right? Make sure you don't have a bug, for example, if you don't sort >captures, and you find a capture with negative SEE, you still need to check the >other captures... (it's a good idea to sort them according to SEE score). > Cutting by SEE migh lose some good captures (for example, a N takes pawn, >which is defended by another pawn, but discovers a bishop attack against enemy >queen), but the tree reduction is so big that the overall result is clearly >positive. At least for me, and I think, for most programs. > If you have any doubt with implementation, you can post some code here and >I'll try to help. > > José C. Thanks for your proposal, but I think the code does well. I have checked about hundret positions where SEE with negative score proposed a cutoff in quiescense where a cutoff should not be made. Second I have a fast not reliable SEE algorithm implemented totally different and checked diffenrent results of these two algorithms. I allways found a problem whith the principle of a static exchange evaluator, not a bug in a code. Typical problems are: 1. Somhow pinned pieces 2. Pieces defending two fields (you can exchange with a little loss to leave another piece in another field undefended) I am currently using SEE for capture sorting only. Greetings Volker
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.