LLR: 2.95 (-2.94,2.94) [-1.50,4.50]Eelco de Groot wrote:From a general search point of view, I'm keeping fingers crossed for this patch from Jörg. It just might pass! But then it still would have to go to LTC.Eelco de Groot wrote: You have no control over nullmove with this, because that is a separate reduction and if nullmove is succesful you only can check it with the verification search which can be extremely shortened.
No null-move during verification search. sprt @ 15+0.05 th 1
LLR: 0.25 (-2.94,2.94) [-1.50,4.50]
Total: 3470 W: 668 L: 650 D: 2152
LLR: 0.33 (-2.94,2.94) [-1.50,4.50]
Total: 6048 W: 1162 L: 1134 D: 3752
LLR: 0.93 (-2.94,2.94) [-1.50,4.50]
Total: 9396 W: 1799 L: 1741 D: 5856
LLR: 0.83 (-2.94,2.94) [-1.50,4.50]
Total: 9684 W: 1846 L: 1791 D: 6047
LLR: 1.42 (-2.94,2.94) [-1.50,4.50]
Total: 13684 W: 2632 L: 2545 D: 8507
Total: 27714 W: 5347 L: 5168 D: 17199
It passed STC! Congrats to Jörg. This should be applicable to every chessprogram using nullmove, which we can assume is almost 100% of reasonably developed efforts (but not all use a verification search). But it has to scale which we don't know because, at STC, verification is tested but in a limited way because of the starting depth.
. But this interests me, I will have a look why it behaves like this.
