Allowing null move pruning in the endgame.

[JimmyRustles]

I changed my null move pruning code to allow it to prune in the endgame and I've seen some great results with it. The compensation is that I decrease the null move search reduction from 3 to 2 in the endgame.

I used to not allow any null move pruning if there are 3 or fewer non-pawn pieces for the side to move. I took that condition out and created a function that gives the game phase between 0 and 100 where 0 is opening and 100 is endgame (this is the same code tapered eval uses on the wiki but scaled from 0 to 100). If the game phase is >= 85, I search with a reduction of 2 instead of 3.

I just tested it and it passed sprt with 53 elo difference!

Score of raven_new vs raven_old: 191 - 118 - 166 [0.577] 475
Elo difference: 53.82 +/- 25.35

Also, I've got a test in my engine that searches 30 positions to depth 11 and returns the total nodes searched. The old version was 10.4 million nodes, the new version is 8.9 million nodes. So it seems like it's doing some heavy pruning that it would've avoided before.

Might be something worth trying in your engines.

[bob]

Most have done so. A good test is fine#70. Try it with and without your change. Null-move really fails when zugzwang is present. Because not having to move is a REAL advantage in such positions.

If, by endgame, you mean something more than positions with no pieces present, that is problematic. If pieces are present, you simply have to tune the material threshold you use to turn null-move off. Crafty uses no-pieces == no-null-move. This has varied over the years from a high of maybe 9 (queen) down to the current value of 3 (one piece).

YMMV

[Terje]

I changed my null move pruning code to allow it to prune in the endgame and I've seen some great results with it. The compensation is that I decrease the null move search reduction from 3 to 2 in the endgame.

I used to not allow any null move pruning if there are 3 or fewer non-pawn pieces for the side to move. I took that condition out and created a function that gives the game phase between 0 and 100 where 0 is opening and 100 is endgame (this is the same code tapered eval uses on the wiki but scaled from 0 to 100). If the game phase is >= 85, I search with a reduction of 2 instead of 3.

I just tested it and it passed sprt with 53 elo difference!

Score of raven_new vs raven_old: 191 - 118 - 166 [0.577] 475
Elo difference: 53.82 +/- 25.35

Also, I've got a test in my engine that searches 30 positions to depth 11 and returns the total nodes searched. The old version was 10.4 million nodes, the new version is 8.9 million nodes. So it seems like it's doing some heavy pruning that it would've avoided before.

Might be something worth trying in your engines.

Have you tried allowing null moves as long as the side to move has 1 or more non-pawn pieces?

[jdart]

> Have you tried allowing null moves as long as the side to move has 1 or more non-pawn pieces?

That is usually safe. But I have had to reduce null pruning also for the case where there is one minor on board.

--Jon

[xr_a_y]

Maybe, instead of just number of pieces/pawn, their mobility will be more interesting ?

[Karlo Bala]

I changed my null move pruning code to allow it to prune in the endgame and I've seen some great results with it. The compensation is that I decrease the null move search reduction from 3 to 2 in the endgame.

I used to not allow any null move pruning if there are 3 or fewer non-pawn pieces for the side to move. I took that condition out and created a function that gives the game phase between 0 and 100 where 0 is opening and 100 is endgame (this is the same code tapered eval uses on the wiki but scaled from 0 to 100). If the game phase is >= 85, I search with a reduction of 2 instead of 3.

I just tested it and it passed sprt with 53 elo difference!

Score of raven_new vs raven_old: 191 - 118 - 166 [0.577] 475
Elo difference: 53.82 +/- 25.35

Also, I've got a test in my engine that searches 30 positions to depth 11 and returns the total nodes searched. The old version was 10.4 million nodes, the new version is 8.9 million nodes. So it seems like it's doing some heavy pruning that it would've avoided before.

Might be something worth trying in your engines.

When there are only a few pieces on the board, IMO it is a good practice to look if those pieces have safe squares (especially knights since knight can't get tempo) before deciding to do a null move. Perhaps you should look at the Critter source code.