Nullmove bugs

[elpapa]

if (depth >= 4 && nodetype != NodeTypePV && !incheck && PopCount(b->sidemask[b->side] > 2)) {
[­/code]

How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.

Nullmove reduces by R + 1. My R is 3, so 3 + 1 = 4. I'll fiddle about with it after this latest test (requiring 4 or more pieces for the side to move) runs to completion.

Yes, but you can still do null move pruning, even if the remaining depth is less than 4.

You *can*, but the overhead of doing it at low depths starts to outweigh its benefits. Dorpsgek is an incredibly slow program at ~700knps. An extra 2 million nodes of overhead costs Stockfish little, but it costs Dorpsgek a lot more.

Ok, then there's a reasoning behind it. I thought that maybe you hadn't considered it.

[zenpawn]

2: aren't you trying calling null move pruning when it's not necessary? for example when static_eval << beta

Question about this. Does this mean the benefit of only checking the null move in eval > beta cases outweighs the cost of calculating the static evaluation at every node (vs just qsearch nodes)?

[ZirconiumX]

The proof will lie in the Elo, I suppose.

Though really I should do something about the performance of it. If TSCP had a smarter search, it would outsearch Dorpsgek easily.

While a conversion to Make/Unmake would probably be a good idea, there is an awful lot of information and board state that needs to be updated, so I suspect the recalculation may offset the memory bandwidth.

[thomasahle]

You *can*, but the overhead of doing it at low depths starts to outweigh its benefits. Dorpsgek is an incredibly slow program at ~700knps. An extra 2 million nodes of overhead costs Stockfish little, but it costs Dorpsgek a lot more.

As a data point, Sunfish is only around 30knps and it still benefits from doing null moves all the way down to depth=1. For slow engines as much as fast, pruning is key.

[ZirconiumX]

Well the "4 or more pieces to nullmove" patch is a slight loss, but now within error bounds.

Code: Select all

Score of New vs Old: 1311 - 1343 - 719  [0.495] 3373
ELO difference: -3.30 +/- 10.39
SPRT: llr -2.95, lbound -2.94, ubound 2.94 - H0 was accepted

I suppose you're right, Thomas.

Now I'll see if lowering the depth requirement helps.

[bob]

if (depth >= 4 && nodetype != NodeTypePV && !incheck && PopCount(b->sidemask[b->side] > 2)) {
[­/code]

How did you come up with depth >=4? Depth >= 2 works best for me. Make sure you call qsearch when depth <= 0 and not depth == 0 if you make this change.

Nullmove reduces by R + 1. My R is 3, so 3 + 1 = 4. I'll fiddle about with it after this latest test (requiring 4 or more pieces for the side to move) runs to completion.

Yes, but you can still do null move pruning, even if the remaining depth is less than 4.

You *can*, but the overhead of doing it at low depths starts to outweigh its benefits. Dorpsgek is an incredibly slow program at ~700knps. An extra 2 million nodes of overhead costs Stockfish little, but it costs Dorpsgek a lot more.

This is wrong. NULL-MOVE should NOT "add extra overhead". It reduces the size of the tree, which is why we use it. Otherwise it would be worthless.

[ZirconiumX]

I was referring to null move fail lows.

Also, if somebody found a way of ordering moves perfectly, I suspect people would use that instead of theoretically unsound pruning that causes imperfections.

But that's besides the point.

Current SPRT progress on depth >= 3:

Code: Select all

Score of New vs Old: 837 - 761 - 632 [0.517] 2230
ELO difference: 11.85 +/- 12.20
SPRT: llr 1.76, lbound -2.94, ubound 2.94

We have a positive elo result! But it's nothing earth shattering. More testing to be done later.

[bob]

I was referring to null move fail lows.

Also, if somebody found a way of ordering moves perfectly, I suspect people would use that instead of theoretically unsound pruning that causes imperfections.

But that's besides the point.

Current SPRT progress on depth >= 3:

Code: Select all

Score of New vs Old: 837 - 761 - 632 [0.517] 2230
ELO difference: 11.85 +/- 12.20
SPRT: llr 1.76, lbound -2.94, ubound 2.94

We have a positive elo result! But it's nothing earth shattering. More testing to be done later.

Ordering is not the issue here, it is effort, as in search space. null-move searches a MUCH smaller tree than a single normal move would search, because of the reduced depth. The null-move observation, as defined by Beal, actually works and is not nearly as speculative in nature as forward-pruning approaches.

Last time I tested, removing null-move cost me 40 Elo. Removing LMR cost me 40 Elo. Removing both cost me 120 Elo. That has probably increased over the last few years...

[zenpawn]

Is the nodetype != NodeTypePV condition a requirement of null move pruning? I ask because when I added that restriction, my search became painfully slow.

[Evert]

Is the nodetype != NodeTypePV condition a requirement of null move pruning? I ask because when I added that restriction, my search became painfully slow.

Shouldn't matter that much. There aren't that many PV nodes, but if the null-move fails high (which might get backed up to the root and trigger a research with a larger aspiration window) it might be costly, especially if the fail-high is undeserved. I guess it will depend a lot on how you handle your aspiration window and other minor details.

EDIT: I just tried with Jazz; allowing null-move in the PV adds about 2% to the node count for a fixed depth search (NPS is constant, so the time to depth increases by a similar 2%). Seems it should just be a speed optimisation to not do it in PV nodes.