Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

RPGeezus

Null-Move pruning in Chess

This topic is 5223 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quick question about null-move pruning. Everything I''ve read indicates not to try two null-moves in a row. What does this mean exactly? Obviously you wouldn''t want to try doing a null-move during a null-move check (nothing would ever happen except the side to move would switch). So does this mean if I pruned null moves at ply 1 I shouldn''t ever try to prune on ply 2? Or does it mean what I stated above: Don''t try null-move pruning while checking to see if you can null-move prune? I''ve tested my program while it does a null-move check on every ply and it seems to play okay.. (Ply 6 in about 1 second, 1.7 Million nodes / sec on a P4 2.4GHz, 512MB Ram, 0xFFFFF entry transposition table). Will

Share this post


Link to post
Share on other sites
Advertisement
It means "Don''t try null-move pruning while checking to see if you can null-move prune."

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It means if you''ve done a nullmove at ply P don''t try one at ply P+1.

For instance your search can look like:
1. e2e4 NULL 2.d2d4-NULL <leaf>

but not
1. e2e4 NULL 2.NULL d7d5 <leaf>
or even worse:
1. e2e4 NULL 2. NULL NULL <leaf>

So in your search you have to remember plies you do nullmove.

If you don''t put restriction this is very dangerous and your program will make more tactical blunders. As you can see in case (3), with successive null moves your depth 4 search can in fact degenerate into depth 1, which is a very bad idea!

Share this post


Link to post
Share on other sites
AP: Are you agreeing with Alvaro?

So in other words, don''t try a null-move if an ancestor node was a null move.

Thanks,
Will




Share this post


Link to post
Share on other sites
What the AP said and what I said are different things. Your interpretation applies to my version. What the AP said is: "Don't try a null-move if the last move tried was a null-move." So even if an ancestor was a null-move, you are allowed to try null-moves, as long as you never try two null-moves in sequence. I think this is what most people use, and it's sometimes refered to as "recursive null-move pruning".

While both are valid options (and you should try them both in your program), recursive null-move pruning is likely to give you better results.



[edited by - Alvaro on June 6, 2004 2:33:41 PM]

Share this post


Link to post
Share on other sites
That clears things up quite a bit.

It sounds as if recursive null-move pruning would be quite a bit faster.

I''m using verified null-move pruning in my own program but I suspect that recurisive null-move pruning would ''break'' the reliability of this method. Am I being overly cautious?

Thanks,
Will

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!