Author: Volker Böhm
Date: 00:37:23 08/08/04
Go up one level in this thread
On August 07, 2004 at 17:46:55, Stuart Cracraft wrote: >On August 07, 2004 at 17:24:48, Volker Böhm wrote: > >>Hi Stuard, >> >>move sorting with SEE gave ca. 5% less nodes, (had kind of MVV/LVA before). >> >>Have a cuttoff in qsearch if stand_pat + margin < alpha nextove allready. Then I >>tried to cutoff with SEE too (if SEE < 0 then nextmove). This doesn´t work well >>for me. It reduces node count by about 30%, but plays worse. >> >>Greetings Volker > >Volker, does your program have a complex or simple evaluation? >How expensive is your attack-square/defend-square method? > >Stuart Hi Stuart, our program (it has two authors) has an incrementally built attack table with 8 Bits for the attacks for every color. Thus the evaluation of a "bad" SEE value is only one table lookup on a table indexed by 16 bit. I use this "bad" SEE value for move ordering. The SEE value is "bad" because it does not handle rooks, queens or bishops behind other rooks, queens or bishops in a row or diagonal. For move ordering this "bad" SEE is nearly as good as a real SEE. It has about 98% the same value as the right SEE. For cutoffs in q-search I use the "bad" SEE for predecision. I only apply a "real" SEE if the "bad" SEE says "cutoff". My real SEE is fast (based on 0x88), and with the predecision it takes non measurable speed if used for q-search pruning. Example: WMTEST (100 positions) with fixed depth of 8 without SEE-Pruning in Q-Search: 199132939 Nodes 491686 Nodes/s With SEE-Cutoffs (Cutoff iff SEE Value < 0, thus loosing material): 144411284 Nodes 492871 Nodes/s 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.