static pruning/null move idea

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

static pruning/null move idea

Postby Daniel Shawul » 11 Mar 2007, 07:14

I have an idea on how to reduce the cost of null move at leaf nodes. When the depth >= 4, assuming null move reduction factor of 3, the null move search will be a quiescnece search. The idea is to use lazy_evaluation for this search. This speeds up the scorpio's search by 12%, and still finding all the mate threats. The search result is not stored in hash table to avoid instablitites caused by a different search. With static pruning mate threats can not be found and is still not safe as no search (some do swap off) is done. I found this to be an easy alternative to static pruning. What do you think?
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Re: static pruning/null move idea

Postby mjlef » 11 Mar 2007, 12:08

I guess you will just have to test to see what is better. When I added checking moves at depth=0 and some other qsearch depths, I found it OK to use R+3 in NULL. So I think you might need to use a real search here, or somehow detect what safe checking moves might be available. I actually have a move generator that does this, and it is not hard to write. Another idea is to just use static analysis to find one move which you extect to be above beta. And you could use static analysis for the kings to see if it might be safe to prune (if a king is threatned, maybe you need to include checks). If you are both ahead and have one winning capture, maybe this is OK. For fail low nodes, I do not see any fast method. Maybe if the eval score is way outside the window, it mgiht be safe, but not having checks might hurt.
mjlef
 
Posts: 64
Joined: 29 Mar 2006, 22:04

Re: static pruning/null move idea

Postby Daniel Shawul » 12 Mar 2007, 08:26

From my testst, it seems that it is better to use the normal null move in the end game. The positional terms could up to a large value and cause a null move fail high. The main idea was ,since it is hard to find a positional fail high with a qsearch null move, it might be good to consider only tactical terms (with lazy eval).
Ofcourse we are gambling that the king safety , passed pawns and other huge positional terms will not increase by much from the point the qsearch is called. For those who have a sophisctacted qsearch, this might not be a good idea at all. But for some of us who use futliliy pruning, lazy eval and other material based prunings at the leaves it might be worth a try.

I think that detecting mate threats is important whether the current eval is above beta or below alpha, with high null move depth reduction R =3. I do not use eval() >= beta to try null moves just because i want to detect all possible mate threats. With that criteria the null move cutoff efficiency increases but not good overall.
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Re: static pruning/null move idea

Postby Peter Fendrich » 12 Mar 2007, 23:19

I am a bit confused of what I think you are saying....
Maybe we are using the term Lazy Eval different.
Do you mean that you are replacing the quiscence search with a lazy eval for those depths?
Does your Lazy Eval include SEE?
For instance white is to move and the white Queen is pinned to King by a black Bishop . Now instead of a white null move you execute a Lazy Eval. How do you see that the Queen is trapped?

/Peter
User avatar
Peter Fendrich
 
Posts: 193
Joined: 26 Sep 2004, 20:28
Location: Sweden

Re: static pruning/null move idea

Postby Daniel Shawul » 13 Mar 2007, 12:06

No the search is all the same except that null move searches with depth <= 4 are all done using lazy evaluation only throught out quiecence search. This is just like a big swap off but including check moves, detecting illegal moves , and whatever is added to qsearch.
Doing null move search trees a bit different from the normal search. It might be also a good idea to include more threat extension in null move searches... etc
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Re: static pruning/null move idea

Postby Peter Fendrich » 14 Mar 2007, 22:12

Ok, that makes more sense :)

It sounds like an interesting idea. One have to be careful to not increase the probelm with Nullmove in stalemate and "forced move" positions.

Another way could be to lowering the "LazyEval limit" in a normal Eval.

/Peter
User avatar
Peter Fendrich
 
Posts: 193
Joined: 26 Sep 2004, 20:28
Location: Sweden

Re: static pruning/null move idea

Postby Tony van Roon-Werten » 16 Mar 2007, 08:57

Daniel Shawul wrote:No the search is all the same except that null move searches with depth <= 4 are all done using lazy evaluation only throught out quiecence search. This is just like a big swap off but including check moves, detecting illegal moves , and whatever is added to qsearch.
Doing null move search trees a bit different from the normal search. It might be also a good idea to include more threat extension in null move searches... etc


Sounds interesting. Maybe add some exceptions, ie after a passedpawnpush, full eval is redone and the new value is sent down.

Maybe not only use it after nullmove. How about when going into quiescence and static eval < alpha+2 pawns ?

You will only improve alpha if some wood is hanging. This simple quiesence will notice that and then you can research.

Some other things are nescessairy, but lets wait for some other people to think about it and give some (feed)back.


Tony
Tony van Roon-Werten
 
Posts: 99
Joined: 02 Oct 2004, 15:31
Location: 's Hertogenbosch, Netherlands

Re: static pruning/null move idea

Postby Daniel Shawul » 16 Mar 2007, 17:31

yes that is probably the reason why it didnt work for me in the endgames. I am now trying to do full evaluations after pawn pushes to 7th rank , and caputre of a pawn on the 7th rank.
That is actually what i do in my normal lazy evalution, dont know why i forgot to add it in this one.

As you suggested, it can be used also score < alpha + 200.
At depth == 1, just futility pruning might be better.
But for for depths == 2, 3, 4 it might be used with the still lower margin 200, assuming we will be safe from the additional search. If this is done , a separte hash table to store results calcualted from lazy evaluation searches might be a good idea.

Daniel
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 42 guests