zamar wrote:
Why could it not happen? It's called search instability. (Or maybe I missed your point again?)
My point was from the very beginning the question about why one should test the result of a null-window search around alpha against beta in PV case. From my unexperienced point of view this seems surprising. I also missed a source comment concerning this matter. Your first answer didn't address my question. I'm sorry if I was not clear enough.
It seems you talk about search instability in a rather self-evidently manner, not worth to explain something. On the other hand SF is "famous" for it's instable search behaviour. Therefore I think this is still an interesting issue, aside from the opportunity for me to learn something new.
Ralph Stoesser wrote:
It seems you talk about search instability in a rather self-evidently manner, not worth to explain something. On the other hand SF is "famous" for it's instable search behaviour. Therefore I think this is still an interesting issue, aside from the opportunity for me to learn something new.
Yes, SF has very unstable search, but I do not think it's a bad thing. The sources of unstability are A) history heuristic which affects move ordering which affects move count based pruning B) transposition table. There might be more, I'm not sure...
Being highly selective with many researches and always saving the best move in TT has its advantages. We get deep quickly and each research examines new moves which improves the quality of the tree.There is some similarity with Monte Carlo method.