Quiescence Search for SEE > 0, not SEE = 0

[jacobbl]

I've just tested doing Quiescence Search when I've a good capture, and not an equal capture. On the WAC testsuit it scored better then the normal version. After running 4400 games (400 games against 11 different engines) 40 move 1 min, I got a score of 64,1% for the new version vs 64,6% for the original version (SEE >= 0). This is within the error margin. I was a bit surprised because I was suspecting the new version to be far worse than the old one.

I'm wondering if I might have an error in my SEE function (I doubt it, but you never know) or my evaluation function is so bad that the equal captures aren't that important to test.

Does anybody know if this is normal result or should I suspect an error somewhere?

Regards
Jacob

[bob]

I've just tested doing Quiescence Search when I've a good capture, and not an equal capture. On the WAC testsuit it scored better then the normal version. After running 4400 games (400 games against 11 different engines) 40 move 1 min, I got a score of 64,1% for the new version vs 64,6% for the original version (SEE >= 0). This is within the error margin. I was a bit surprised because I was suspecting the new version to be far worse than the old one.

I'm wondering if I might have an error in my SEE function (I doubt it, but you never know) or my evaluation function is so bad that the equal captures aren't that important to test.

Does anybody know if this is normal result or should I suspect an error somewhere?

Regards
Jacob

It is certainly trivial to test. I have always done >= 0 because even exchanges can produce significant positional score changes. Bxf3 gxf3 for example...

[Ferdy]

I've just tested doing Quiescence Search when I've a good capture, and not an equal capture. On the WAC testsuit it scored better then the normal version. After running 4400 games (400 games against 11 different engines) 40 move 1 min, I got a score of 64,1% for the new version vs 64,6% for the original version (SEE >= 0). This is within the error margin. I was a bit surprised because I was suspecting the new version to be far worse than the old one.

I'm wondering if I might have an error in my SEE function (I doubt it, but you never know) or my evaluation function is so bad that the equal captures aren't that important to test.

Does anybody know if this is normal result or should I suspect an error somewhere?

Regards
Jacob

do you consider attackers/defenders that are pinned to the king? example situation from the opening position, e4 d5 Qe2 e6 exd5, black can not play exd5 because of Q in e2, do you consider exd5 in your see()?

[bhlangonijr]

I've just tested doing Quiescence Search when I've a good capture, and not an equal capture. On the WAC testsuit it scored better then the normal version. After running 4400 games (400 games against 11 different engines) 40 move 1 min, I got a score of 64,1% for the new version vs 64,6% for the original version (SEE >= 0). This is within the error margin. I was a bit surprised because I was suspecting the new version to be far worse than the old one.

I'm wondering if I might have an error in my SEE function (I doubt it, but you never know) or my evaluation function is so bad that the equal captures aren't that important to test.

Does anybody know if this is normal result or should I suspect an error somewhere?

Regards
Jacob

do you consider attackers/defenders that are pinned to the king? example situation from the opening position, e4 d5 Qe2 e6 exd5, black can not play exd5 because of Q in e2, do you consider exd5 in your see()?

I think it would never be necessary, if you test for the legality of the move before picking it - as in my case. Do you use see() before testing for the legality of the moves?

Regards,

[Ferdy]

I've just tested doing Quiescence Search when I've a good capture, and not an equal capture. On the WAC testsuit it scored better then the normal version. After running 4400 games (400 games against 11 different engines) 40 move 1 min, I got a score of 64,1% for the new version vs 64,6% for the original version (SEE >= 0). This is within the error margin. I was a bit surprised because I was suspecting the new version to be far worse than the old one.

I'm wondering if I might have an error in my SEE function (I doubt it, but you never know) or my evaluation function is so bad that the equal captures aren't that important to test.

Does anybody know if this is normal result or should I suspect an error somewhere?

Regards
Jacob

do you consider attackers/defenders that are pinned to the king? example situation from the opening position, e4 d5 Qe2 e6 exd5, black can not play exd5 because of Q in e2, do you consider exd5 in your see()?

I think it would never be necessary, if you test for the legality of the move before picking it - as in my case. Do you use see() before testing for the legality of the moves?

Regards,

Yes I use see() before testing the legality of a move.
I use the see() result to sort moves for move ordering, but I have added calculations to not include all attacker/defender pawn moves that are pinned.

[bhlangonijr]

Yes I use see() before testing the legality of a move.
I use the see() result to sort moves for move ordering, but I have added calculations to not include all attacker/defender pawn moves that are pinned.

I also use see() to sort moves before testing for legality but the illegal move will be excluded anyway regardless. Do you think this extra code in the see() function is worth it ( If at all)?

[Ferdy]

Yes I use see() before testing the legality of a move.
I use the see() result to sort moves for move ordering, but I have added calculations to not include all attacker/defender pawn moves that are pinned.

I also use see() to sort moves before testing for legality but the illegal move will be excluded anyway regardless. Do you think this extra code in the see() function is worth it ( If at all)?

My experience showed that adding a little bit of accuracy to anything and doing it right is a winner. There might be a slowed down but this can probably be offset by using that feature to prune or reduce perhaps the search depths somewhere. It is just like if you exert effort on something, try to save as much as possible from it and use it at some applicable areas. I am reducing captures and I need my see() to be accurate as much as possible.

[bhlangonijr]

Yes I use see() before testing the legality of a move.
I use the see() result to sort moves for move ordering, but I have added calculations to not include all attacker/defender pawn moves that are pinned.

I also use see() to sort moves before testing for legality but the illegal move will be excluded anyway regardless. Do you think this extra code in the see() function is worth it ( If at all)?

My experience showed that adding a little bit of accuracy to anything and doing it right is a winner. There might be a slowed down but this can probably be offset by using that feature to prune or reduce perhaps the search depths somewhere. It is just like if you exert effort on something, try to save as much as possible from it and use it at some applicable areas. I am reducing captures and I need my see() to be accurate as much as possible.

I agree with that. My point is that in this particular case considering pins against the king is not doing any good because the move affected by it will be discarded afterwards. In other words, this extra knowledge will only "improve" the accuracy for illegal moves. Or am I missing something?

[jacobbl]

I don't discard illegal moves from my SEE(). I will try to change my SEE(), and maybe it will help, because I also prune bad captures (making correct SEE important).

I still wonder if anybody has an opinion if the time saved on not doing Quiescence Search for SEE = 0 offsets the lost accuracy.

Regards Jacob

[Ferdy]

Yes I use see() before testing the legality of a move.
I use the see() result to sort moves for move ordering, but I have added calculations to not include all attacker/defender pawn moves that are pinned.

I also use see() to sort moves before testing for legality but the illegal move will be excluded anyway regardless. Do you think this extra code in the see() function is worth it ( If at all)?

My experience showed that adding a little bit of accuracy to anything and doing it right is a winner. There might be a slowed down but this can probably be offset by using that feature to prune or reduce perhaps the search depths somewhere. It is just like if you exert effort on something, try to save as much as possible from it and use it at some applicable areas. I am reducing captures and I need my see() to be accurate as much as possible.

I agree with that. My point is that in this particular case considering pins against the king is not doing any good because the move affected by it will be discarded afterwards. In other words, this extra knowledge will only "improve" the accuracy for illegal moves. Or am I missing something?

Sorry I don't get your point exactly.
Here is a case where accuracy is important in see(). There are certain positions that see() will report >= 0 where in fact it is < 0 why because I did not consider pins, and there are certain positions that see() will report < 0 where in fact it is >= 0 why because I did not consider pins also. Search efficiency is affected, lost opportunities to draw or to win, mis-informed move ordering scores. Every heuristics that uses see() become garbage.