if (val + value(captured)+ 150 < alpha) skipmove;
I did have K as 7, but I just changed it to 0, since I assumed king capturing pieces would be better than any other piece as the king can't be recaptured. Although I only work with legal moves, so might be minutely faster to make K=7, then check the legality of the king move before playing it, but thats a minor issue at the moment.
Perhaps the best thing I can do is setup a very simple board with a small capture sequence which goes quiet after a few ply, then analyse all the moves and mvvlva and see values by hand to make sure it corresponds
Whatever you do, take care to do the right comparison. When talking about 2% more nodes using SEE, please make sure that exactly *everything* else except skipping moves with SEE<0 is identical in your program versions on the left and right sides.
If that is the case then proceed as you mentioned: find a small example where this unexpected increase of nodes already happens. It might help to have a function that prints the whole tree being searched to a file.
But the total nodes searched is actually 2% more using SEE, than without
The counter-intuitive result (that pruning increases node count instead of decreasing it markedly) suggests a bug in SEE.
Here are a couple of suggestions to test against your code.
[1] The order in which lowest-value attackers are obtained should be PNBRQK.
[2] The value of K should be larger than Q, to ensure that any move into check gets a negative SEE result.
But the total nodes searched is actually 2% more using SEE, than without
The counter-intuitive result (that pruning increases node count instead of decreasing it markedly) suggests a bug in SEE.
Here are a couple of suggestions to test against your code.
[1] The order in which lowest-value attackers are obtained should be PNBRQK.
[2] The value of K should be larger than Q, to ensure that any move into check gets a negative SEE result.
Hi Robert,
I don't think that your valid points [1] and [2] actually have an influence on the node count of the OP's program since he reported to search legal moves only. Also, if it had an influence then it should be the same for both cases, with and without SEE-based pruning of losing captures.
A bug in SEE could only lead to pruning too many captures or too few captures, but not to pruning "less than nothing", where "nothing" is the claimed behaviour on the "without" side. Therefore something must be wrong with the comparison of the "with SEE" and "without SEE" cases, and/or the "without" case prunes something that is not pruned with SEE.
Sven Schüle wrote:A bug in SEE could only lead to pruning too many captures or too few captures, but not to pruning "less than nothing", where "nothing" is the claimed behaviour on the "without" side.
Hi Sven
The paradox can be explained.
Suppose that the first move in QS is truly the best, and is the only move that can lead to a cutoff.
If that move gets pruned (owing to a bug in SEE) then all the other moves have to be searched, with an increase in node count.
I tested this by putting a gross bug in my SEE, and got 50% more nodes than with no pruning at all.
Colin described his SEE method earlier in the thread, but has not posted code.
Sven Schüle wrote:A bug in SEE could only lead to pruning too many captures or too few captures, but not to pruning "less than nothing", where "nothing" is the claimed behaviour on the "without" side.
Hi Sven
The paradox can be explained.
Suppose that the first move in QS is truly the best, and is the only move that can lead to a cutoff.
If that move gets pruned (owing to a bug in SEE) then all the other moves have to be searched, with an increase in node count.
I tested this by putting a gross bug in my SEE, and got 50% more nodes than with no pruning at all.
Colin described his SEE method earlier in the thread, but has not posted code.
Hm, sounds right. It assumes, though, that the truly best move in QS happens to be a sacrifice more or less frequently since SEE (as applied in the case we are discussing here) is used for "aggressor > victim" only. Of course a possible bug could also return a negative SEE value even if "victim" is not defended, so the capture was actually no sacrifice at all.
In any case, Colin should check his SEE carefully again.