Two questions

[jd1]

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

[hgm]

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.

[lucasart]

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.

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).

[hgm]

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

[jdart]

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]

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]

Thanks to all for the very helpful replies!

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).

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.

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

[jd1]

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

[hgm]

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.

[lucasart]

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...