Author: Tony Werten
Date: 00:30:03 04/21/04
Go up one level in this thread
On April 20, 2004 at 12:42:14, Tord Romstad wrote:
>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.
I have a full static mate detection wich can detect up to mate in 7. I call it
for side to move.
Calling it for side not to move seems to be more expensive than just doing a
nullmove.
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 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.