tpetzke wrote:I was referring to the case where you store just a flag that the null move in that node will likely fail low (because of threats present) along with the usual information of that node in the TT.
I dont think a flag makes a lot of sense either. It tries to resolve a non existant problem (tt pruning in child is cheap) in a somewhat clumsy way.
What I do to avoid useless null searches is use the TT to predict a fail low. If the TT entry is at least as deep as th3 depth of a null search, and gives a fail low score (exact or upper bound score <= alpha) then you can safely skip the null search. If no move could beat alpha, then, a fortiori, a null move wont. AFAIK this trick is from Crafty.
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
If the TT entry is at least as deep as th3 depth of a null search, and gives a fail low score (exact or upper bound score <= alpha) then you can safely skip the null search.
I'm aware of that trick and in previous versions I used it. Currently I don't. I rather do the null move and get a threat move if it fails low. But unlike crafty (might be different now, it is been a while since I looked) I restrict when to do the null move to cases where the static eval is within a certain limit of beta.
If the position is already bad doing nothing probably won't make it better.
