For those that like to toy with Ethereal...

[AndrewGrant]

No difference in my test, but I discovered that Arena was logging like mad (I had a 550 MB arena.debug file) so I think the result cannot be trusted.

Code: Select all

   Program                          Elo    +   -   Games   Score   Av.Op.  Draws
 1 Ethereal-stopr                 : 3333   11  11  1475    50.1 %   3333   58.6 %
 2 Ethereal-ethpr                 : 3333   11  11  1475    49.9 %   3333   58.6 %
 

Code: Select all

NMPFormula vs master DIFF

ELO   | 0.62 +- 1.98 (95%)
SPRT  | 10.0+0.1s Threads=1 Hash=8MB
LLR   | -2.96 (-2.94, 2.94) [0.00, 5.00]
Games | N: 46370 W: 9180 L: 9097 D: 28093

Not bad, but Ill stick with current master.

[Michael Sherwin]

You can get a very close approximation to the Stockfish null move pruning with this formula:

Code: Select all

        R = ( ( 13 + depth ) >> 2 ) + MIN(3, (eval - beta) / 185);

I was still using the old log formula in RomiChess. This one works better. RomiChessX 55.5/100 against last released RomiChess. Did another 100 game test with same result. Formulas like these are going to constantly be a moving target as algorithms and hardware get faster. The question about null move that needs answered is the max useful depth. Let's assume some exaggerated numbers. If the search depth remaining is 20 or 30 or 40 does null move need to be searched any more than say 12 ply or maybe only 10 ply is needed. If the side that is given two moves in a row cannot pull a rabbit out of its hat in 12 ply it seems unlikely that 20 ply will make a difference. Especially when it is not really that sides move anyway.

I'm experimenting with NMR instead of NMP. That let's the engine just call Qsearch and if there is no immediate capture threat the engine does not prune. It only reduces depth by one or two ply and keeps searching. It seems no worse. However, the formula above essentially does only a Qsearch anyway for depths up to 8 or 9 and prunes on just a Qsearch. So, maybe below a certain depth pruning may be best and just reducing the search above that depth. It is like having a verification search for the deeper depths.

[PK]

Recently I noticed that (eval - beta) part of such formulas - I used 3 + depth / 4 += std::min(3, (eval - beta) / 200) - increases time to solution in certain tactial positions, where you need to sacrifice a piece and play a couple of quiet moves material down.