Two questions

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
jd1
Posts: 266
Joined: Wed Oct 24, 2012 12:07 am

Two questions

Post by jd1 » Mon Feb 11, 2013 8:40 am

Hi,

Just a couple of quick questions, firstly, should IID be done at non-PV nodes (in particular Cut-Nodes)? If so, how much elo was this worth for you?

Secondly, is recursive null-move (i.e. the null-move search tries a second null-move) ok or not?

Thanks a lot!
Jerry

User avatar
hgm
Posts: 23613
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Two questions

Post by hgm » Mon Feb 11, 2013 10:08 am

For my engines HaQiKi D and Shokidoki the time-to-depth improved significantly when I preceded every d>2 search in a non-PV node with a d=1 iteration. I guess it helps you to cheaply weed out cut-move candidates that MVV/LVA and SEE-wise look good, but are somehow poisoned by side effects (overloading or soft-pins). I never did an actual Elo measure.

I think almost everyone uses recursive null-move nowadays.

User avatar
lucasart
Posts: 3037
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Two questions

Post by lucasart » Mon Feb 11, 2013 10:14 am

jd1 wrote: should IID be done at non-PV nodes (in particular Cut-Nodes)? If so, how much elo was this worth for you?
Yes, but you need to tweak the conditions properly. Obviously the min depth should be higher for non PV nodes than for PV nodes. After quite a bit of experimenting, I settled for this in DiscoCheck, which worked best for me:
- no hash move (obviously)
- depth >= 4 at PV nodes, and depth >= 7 at non PV nodes (All or Cut)
- if node type is a (predicted) All node, then additional condition eval+pawn >= beta.
jd1 wrote: Secondly, is recursive null-move (i.e. the null-move search tries a second null-move) ok or not?
Everytime I allowed two consecutive null moves to happen (accidently or vollontarly) it was an absolute disaster. I experimented on null move conditions quite a bit, and I strongly recommend that you do not touch the eval >= beta condition from the original Fruit 2.1. Note that Toga's eval is asymetric, because of the tempo bonus, so you need to explicitely forbid recursive null moves (using the search stack to know if the current node is a null search child).

For DiscoCheck I kept the eval symetric, which has the added benefit of enabling a null move speed optimization (after null move don't calculate eval but use parent node eval negated), and the condition eval >= beta prevents recursive null moves just like in Fruit. I actually implemented the tempo bonus in the search rather than in the eval, which, I think, is a better way of doing it (confirmed in testing).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

User avatar
hgm
Posts: 23613
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Two questions

Post by hgm » Mon Feb 11, 2013 11:09 am

I don't think he was asking about consecutive null moves.

jdart
Posts: 3816
Joined: Fri Mar 10, 2006 4:23 am
Location: http://www.arasanchess.org

Re: Two questions

Post by jdart » Mon Feb 11, 2013 3:14 pm

I currently use the same IID conditions for PV and non-PV nodes (depth >= 4 ply). Last time I checked there was not an advantage in having different behavior for a PV node. Most nodes are non-PV nodes anyway.

As others have said recursive null move is standard but you must prevent two consecutive null moves.

Also when doing IID I disable null move for the first ply because a null move cutoff will not generate a best move, and when doing IID the whole purpose is to get a best move.

--Jon

bob
Posts: 20474
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Two questions

Post by bob » Mon Feb 11, 2013 5:20 pm

jd1 wrote:Hi,

Just a couple of quick questions, firstly, should IID be done at non-PV nodes (in particular Cut-Nodes)? If so, how much elo was this worth for you?

Secondly, is recursive null-move (i.e. the null-move search tries a second null-move) ok or not?

Thanks a lot!
Jerry
IID at non-PV nodes (for me) slows things down too much. YMMV.

"recursice null-move" simply means that you can have two null-moves in a single path, but not on consecutive plies. Sounds like you are talking about two consecutive nulls, which has never worked for me.

jd1
Posts: 266
Joined: Wed Oct 24, 2012 12:07 am

Re: Two questions

Post by jd1 » Mon Feb 11, 2013 9:25 pm

Thanks to all for the very helpful replies!
lucasart wrote:
jd1 wrote: should IID be done at non-PV nodes (in particular Cut-Nodes)? If so, how much elo was this worth for you?
Yes, but you need to tweak the conditions properly. Obviously the min depth should be higher for non PV nodes than for PV nodes. After quite a bit of experimenting, I settled for this in DiscoCheck, which worked best for me:
- no hash move (obviously)
- depth >= 4 at PV nodes, and depth >= 7 at non PV nodes (All or Cut)
- if node type is a (predicted) All node, then additional condition eval+pawn >= beta.
I have tried depth >= 7 for non-PV (borrowed straight from DiscoCheck). It is +4 elo, LOS 90% after 3160 games (still running).
lucasart wrote:
jd1 wrote: Secondly, is recursive null-move (i.e. the null-move search tries a second null-move) ok or not?
Everytime I allowed two consecutive null moves to happen (accidently or vollontarly) it was an absolute disaster. I experimented on null move conditions quite a bit, and I strongly recommend that you do not touch the eval >= beta condition from the original Fruit 2.1. Note that Toga's eval is asymetric, because of the tempo bonus, so you need to explicitely forbid recursive null moves (using the search stack to know if the current node is a null search child).
Well, the eval >= beta condition from the original Fruit 2.1 was removed from Toga a long time ago. I tried putting it back in about a month ago but aborted the test after -30 elo or so from 2000 games. Perhaps explicitly forbidding it is the way to go. Does that mean that when I search a null-move with depth-R I should not try another null-move search for the opposite colour?

Actually I am little confused - is there a difference between consecutive and recursive null-moves? HGM mentioned that everyone uses recursive null-move these days? As I understand it, consecutive null-move is playing two null-moves in a row, whereas recursive null-move is using null-move later in the null-move search.
lucasart wrote: I actually implemented the tempo bonus in the search rather than in the eval, which, I think, is a better way of doing it (confirmed in testing).
On my very long TODO list :)

Thanks,
Jerry
Last edited by jd1 on Mon Feb 11, 2013 9:30 pm, edited 1 time in total.

jd1
Posts: 266
Joined: Wed Oct 24, 2012 12:07 am

Re: Two questions

Post by jd1 » Mon Feb 11, 2013 9:28 pm

jdart wrote:I currently use the same IID conditions for PV and non-PV nodes (depth >= 4 ply). Last time I checked there was not an advantage in having different behavior for a PV node. Most nodes are non-PV nodes anyway.

As others have said recursive null move is standard but you must prevent two consecutive null moves.

Also when doing IID I disable null move for the first ply because a null move cutoff will not generate a best move, and when doing IID the whole purpose is to get a best move.

--Jon
Thanks Jon. Actually I once tried IID at non-pv nodes forgetting to disable null-move for the first ply. Of course the result was very poor!

Jerry

User avatar
hgm
Posts: 23613
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Two questions

Post by hgm » Mon Feb 11, 2013 10:25 pm

I usually do null move outside of the IID loop: first I try a null-move search at target depth (reduced, of course), and when that fails it will start the IID loop.

User avatar
lucasart
Posts: 3037
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Two questions

Post by lucasart » Mon Feb 11, 2013 11:55 pm

jd1 wrote: Actually I am little confused - is there a difference between consecutive and recursive null-moves?
Null move search is recursive. However, I recommend you put an arbitrary limitation to it: prevent consecutive null moves. For example:
- OK: white plays a null move (depth=d), black plays a real move (depth=d-R), white plays a null move (depth=d-R-1), etc.
- not OK: white plays a null move (depth=d), black plays a null move (depth=d-R), etc.

I've never tried Vincent Diepeveen's double null move method, but somehow I'm very skeptical about it...
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.

Post Reply