Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: null move efficiency

Author: Sune Fischer

Date: 04:14:55 04/21/04

Go up one level in this thread


On April 21, 2004 at 05:44:51, Tord Romstad wrote:

>On April 20, 2004 at 19:57:00, Sune Fischer wrote:
>
>>>I used to do static mate detection in the past, but had to sacrifice it when
>>>I simplified my attack tables.
>>
>>As always it's a trade off, your new tables are probably faster? :)
>
>Yes, though not very much.  The effect on playing strength seemed to be more
>or less neutral.  When there is no measurable difference in strength between
>two different ways to do something, I tend to prefer the simplest solution,
>in order to reduce the number of potential bugs.

I figured the easiest of all was to get rid of them entirely. :)

>>>This is strange.  I have very rarely seen something like this.  Do you have
>>>any examples of positions where this occurs?  How much did you extend for
>>>mate threats?
>>
>>It happens pretty much in all attacking positions, eg. wac141 takes a lot longer
>>to solve with null-threat extension on.
>>I use half a ply for the extension.
>
>Have you tried to make this more dynamic, like I do?  I haven't tested this
>very thoroughly, but intuitively it seems plausible that it is more useful
>to extend for mate threats when the side to move has an advantage.  It might
>be a good idea to let the amount of extension depend on the static eval.

Yes I have tried this. The result on wac141 is that it still finds the right
move fast, but efter that it has a high score and takes forever to find the
mate.

I'm not convinced that the overall effect is a good one, once you really have a
hold of your opponent it is better to kill him off sooner rather than later.
(see also my post to Uri)

>Very strange.  Here are my results for WAC141 with mate threat extension
>on and off:
>
>Mate extension on, BM extension on:   Solved in 6 plies,   13380 nodes.
>Mate extension on, BM extension off:  Solved in 7 plies,   48236 nodes.
>Mate extension off, BM extension on:  Solved in 9 plies,  156929 nodes.
>Mate extension off, BM extension off: Solved in 9 plies,  156937 nodes.
>
>As you can see, the combination of mate extensions and BM extensions helps
>Gothmog find Qxf4 3 plies earlier, and in less than 10% of the nodes.  This
>is by no means unusual in such positions.  Mate extensions improve the speed
>tremendously in positions where checkmates are important, and seems to have
>very little cost in other positions.

Strange, I can't reproduce this effect at all.
I've read of others who didn't get anything from this so I though it was normal.

>I had very strange results with the BM extension.  I found very few test
>positions where Gothmog performed better with the extension enabled, but
>when playing games the version with the extension consistently scored
>slightly better.

Oh that is interesting, I don't think I ever gave it a chance in real play
because it didn't seem to work even on position where I thought it should work.

>I haven't noticed this problem very often.  It probably depends on your move
>ordering.  In the node following a null move, if the null move failed low
>by a big margin two plies earlier, I search the last refutation move directly
>after the hash table move.

Yeah it could be related to move ordering, although the extension is used in
Crafty and Crafty doesn't have this kind of move ordering.

I also tried searching the refutation move first, but it didn't have a very high
cutoff percentage. I feared that searching it first would reduce general move
ordering and searching it later would trigger a lot of needless threat
extensions on the first moves.

-S.
>Tord



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.