Author: Tord Romstad
Date: 09:42:14 04/20/04
Go up one level in this thread
On April 20, 2004 at 07:45:16, Sune Fischer wrote:
>>>>>2. Don't make a null move if the static eval is far below beta.
>>>>
>>>>Actually, you can drop 2 as well :)
>>>>
>>>>Move ordering is much better if you just nullmove everywhere. That way, you can
>>>>also throw out IID.
>>
>>That's not my experience. Nullmoving everywhere doesn't noticably improve
>>my move ordering, and it increases the size of the game tree (by around
>>15-20%, if I recall correctly). Throwing out IID doesn't help.
>>
>>Perhaps this depends on how your move ordering works.
>
>Number 2 doesn't seem to work for me either, I think the explanation is rather
>simple. A nullmove is relative cheap, if I detect correctly 75% of the time that
>a nullmove is futile, then that still means I detect it wrong 25% of the time.
>As it turns out these 3 savings of a nullmove doesn't outweigh the 1 full search
>which could have produced a fast cutoff.
>The end result is a bigger tree for me.
>
>In principle it can work, but you must be very accurate in guessing when not to
>nullmove because a full search is very expensive.
I do some static threat detection in my eval. Perhaps this is why this
works better for me than for you and Tony.
Another interesting idea by Sergei Markoff, which didn't work for me the last
time I tried, but which is used successfully in SmarThink, is to do a shallow
null move search around alpha before deciding to do the full null move search.
In pseudo code, it looks like this:
if(depth > 3*PLY) {
make_null_move();
null_value = -qsearch(-alpha, -alpha+1);
unmake_null_move();
} else null_value = alpha;
if(null_value >= alpha) {
null_value = -search(-beta, -beta+1, depth-(R+1)*PLY);
if(null_value >= beta) return null_value;
}
>>>In addition, throw out the 2nd half of 1 as well. If my opponent is going to
>>>checkmate me, I want to know so I can extend.
>>
>>I don't understand what you say here. In the 2nd half of 1, I suggested to
>>avoid null move search if you already know (without search) that mate in
>>1 is threatened. What extra information do you expect to get from a null
>>move search?
>
>I think there are some practical problems in detecting when you are mate in 1.
>I requires a lot of coding and a big eval with attack scanning around the king
>etc. A faster implementation of the same thing is simply to nullmove and
>fail-low.
I didn't say it was easy, or even that it was a good idea. What I said was
that *if* you already have a reliable way of detecting (some or all) mate
threats, it might be a good idea to use this information to eliminate
unnecessary null move searches.
By the way, if you are satisfied with detecting a few of the most common
mating patterns, and you are willing to accept rare cases of false matches
(i.e. the static mate detector reports a mate when no mate is there), static
mate detection is neither very difficult nor expensive. It is not worth
the cost if you use it only to decide when to avoid null move searches,
but it is useful when deciding whether or not to search checks in the qsearch.
I used to do static mate detection in the past, but had to sacrifice it when
I simplified my attack tables.
>Btw, extending on threats completely blows up the tree for me, it seems there
>are certain position in the tree where you just have to live with a constant
>mate threat. Practicly all nodes gets extended here and a blowup is unavoidable.
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?
I currently use the following scheme for deciding how much to extend when
the side to move is threatened by mate in one (PLY=60, value of pawn=128):
if(static_eval > 0) extension = 45;
else if(static_eval > -100) extension = 30;
else if(static_eval > -200) extension = 20;
else extension = 0;
>I think it would be better to extend on a newly detected mate threat, ie. the
>ply before we wasn't being mated.
In fact, I think precisely the opposite. If you have the same mate threat
as two plies earlier, there is a serious risk of a horizon effect problem,
and it is even more important to extend. I add half a ply to the mate threat
extension in this case (a special case of the Botvinnik-Markoff extension).
Tord
This page took 0.01 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.