hgm wrote:When you generate only captures when in check, and you have none, what score do you return?
Well, I thought I was returning the static eval in this case, but I was actually returning a checkmate score, so that explains why bad things happened when I didn't generate all check evasions. Still not 100% sure why the tree size exploded but my guess is that the qsearch returning bad results was leading to incorrect move ordering...
And as for the 90% qnodes, I'm counting nodes the same as Bob is (as far as I can tell) and he also sees 90%, so maybe I don't have any problems at all!
hgm wrote:When you generate only captures when in check, and you have none, what score do you return?
Well, I thought I was returning the static eval in this case, but I was actually returning a checkmate score, so that explains why bad things happened when I didn't generate all check evasions. Still not 100% sure why the tree size exploded but my guess is that the qsearch returning bad results was leading to incorrect move ordering...
And as for the 90% qnodes, I'm counting nodes the same as Bob is (as far as I can tell) and he also sees 90%, so maybe I don't have any problems at all!
If you use Bob's definition then
I think that the percentage is not interesting and even with no captures at all you can get more than 90%(for example at the opening position if you search to depth 1 you may get 20 qnodes out of 21 nodes).
I think that the interesting part is to know the number of the additional captures that you need to search because of the qsearch relative to the size of the full tree and it is 0 in the opening position when you search to depth 1.
