It is difficult to see how this could lose Elo: can the presence of more positions in the game history result in a better search? I think it has often been reported that it does, but I am starting to believe that most of these attempts may have tested something else (because this is clearly something that confuses many).
It is difficult to see how this could lose Elo: can the presence of more positions in the game history result in a better search? I think it has often been reported that it does, but I am starting to believe that most of these attempts may have tested something else (because this is clearly something that confuses many).
So instead of actually testing this idea, some (even intentionally!?!?) completely buggy implementation was tested. About 3fold_fix
This clearly supports my suspicions:
syzygy wrote:I think it has often been reported that it does, but I am starting to believe that most of these attempts may have tested something else (because this is clearly something that confuses many).
Maybe you could give it a try yourself? It seems it takes a mathematician to get this right.
Chessbomb recently had live boards, and analysis with stockfish dd, of the australian open.
On a couple of times, the analysis (and markup of erroneous/best moves) was just wrong because of the two-move draw evaluation of stockfish. Quite embarassing.
Sadly the long time control test is going to fail... With the test 95% complete it's currently flirting with the 5% significance level. But even if it ends up above that it will not make the -1elo cutoff imposed by Marco (which I did not know about earlier).
Michel wrote:Sadly the long time control test is going to fail... With the test 95% complete it's currently flirting with the 5% significance level. But even if it ends up above that it will not make the -1elo cutoff imposed by Marco (which I did not know about earlier).
StateInfo* stp = st;
for (int i = 2, rep = 1, e = std::min(st->rule50, st->pliesFromNull); i <= e; i += 2)
{
stp = stp->previous->previous;
if ( stp->key == st->key
&& ++rep >= 2 + (gamePly - i < Search::RootPly))
return true; // Draw at first repetition in search, draw at second repetition in game tree.
}
return false;
}
Ok, so not the patch that on purpose does not detect half the repetitions...
Yes that was weird. But surprisingly that patch didn't do so badly (negative but within error bars). The speedup apparently compensates somewhat for the lack of precision. But of course such a patch could never be merged since it would make SF blunder occasionally.
The correct patch also didn't make the cut but unfortunately one can again not draw any definite conclusions. The current testing strategy for bugfixes/simplifications in SF is such that about 30% of the neutral ones can fail the test. This is discussed in this thread
syzygy wrote:Ok, so not the patch that on purpose does not detect half the repetitions...
Does it?
I have looked into over hundreds of testgames recently, and I couldn't even find a single case of repetition in a cycle of other than 4 plies. In human games, this may happen more frequently, but in engine-engine games it seems rather uncommon. Think about it.
I admit, I have only looked into SF-SF testgames, so other engines may vary. I hope you better understand now why I tried this patch.
P. S. Can you show me 10 games from your engine, where it differed from this 4-plies-repetition?
Ok, so not the patch that on purpose does not detect half the repetitions...
Yes that was weird. But surprisingly that patch didn't do so badly (negative but within error bars). The speedup apparently compensates somewhat for the lack of precision. But of course such a patch could never be merged since it would make SF blunder occasionally.
Michel wrote:The correct patch also didn't make the cut but unfortunately one can again not draw any definite conclusions. The current testing strategy for bugfixes/simplifications in SF is such that about 30% of the neutral ones can fail the test. This is discussed in this thread
