Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Features: Return vs. Effort (new revised table)

Author: Volker Böhm

Date: 23:23:02 07/06/04

Go up one level in this thread


On July 06, 2004 at 14:16:37, Robert Hyatt wrote:

>On July 06, 2004 at 14:09:39, Stuart Cracraft wrote:
>
>>Okay here's a new table with revisions based
>>on input. Now, higher effort and return numbers
>>mean more effort and return. And gone is the
>>value number replaced with Russell's return/effort
>>ratio. Have revised some numbers to try to fit in
>>with some opinions.
>>
>>The higher the third column the more that feature
>>gives in program performance for less work expended.
>>
>>EFFORT   RETURN    RETURN/EFFORT     Feature
>>1          5         5               capture ordering
>>3          4         1.33            null move
>>4          4         1               null move with verification
>>4          4         1               search pv first
>>4          5         1.25            static exchange evaluator
>
>This can make a big difference.  IE once you have a SEE procedure working, you
>can use it to reduce the size of the q-search by over 50%, doubling your search
>speed instantly.  At very low risk.

I get other results in tests with our engine (spike). I tested two types of
q-search pruning:
1. Pruning if eval + piece-to-hit-value + margin < alpha
2. SEE based pruning

Pruning type 1 will only work if you have a "fail-soft" lazy-eval with not too
high margins or no lazy-eval.

Results:
In all three types the reduction is about 1/3 of total nodes.

I tested the amount of wrong prunings done by the types of pruning.

Type 1 with small margin and no lazy eval:
Test of 24 MNodes gives 8 MNodes reduction and 13K Errors, with many not seen
mates in 1.

Type 2:
Test of 24 MNodes gives 8 MNodes reduction and 10K Errors, no problems with
mates but sometimes don´t see very high material loss.

Improvements:
Type 1: With lazy-eval (there is a corellation betwenn lazy-eval margins and
type 1 pruning) and no pruning of checking captures.
Test of 24 MNodes gives 5,5 MNodes reduction and 6 errors (errors caused by
pawns hitting to row 7 or beeing hit on row 7).

Game results with the Type 1 with "improvements" are on average 10-15% better
against other engines than Type 2 prunings (5 Min/Game on Celeron 1,3 GHZ).

Perhaps there are good rules to improve SEE pruning (giving less errors). I
haven´t found them yet.

Greetings


>
>
>
>>4          5         1.25            transposition table
>>4          5         1.25            transposition table with 2-tier replacement
>>3          3         1               history heuristic, killers, other ordering
>>2          1         .5              aspiration
>>2          2         1               iterative deepening
>>2          2         1               pawn hashing w/ complex pawn evaluation
>>3          2         .66             capture extension
>>1          5         5               check extension
>>1          1         1               pawn to 6th/7th extension
>>3          3         1               futility
>>3          2         .66             razoring
>>5          3         .6              mate-at-a-glance



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.