1-What is the proper use of see? right now I'm just using it to ignore losing captures & swaps in the quiescence (only in the case of non evasions),which causes a drop in the strength of the engine ,playing against it's former no SEE enabled version.
2-could this be caused by not handling pins in the SEE ? causing a winning capture to be reported as a losing one !
3-should I order the moves in the Quiescence instead thereby having all moves evaluated (if necessary) even if they are losing captures.
4-how much should SEE influence the result of the search if at all?
for example this is the result of the SEE/less /SEE search (which I think is somewhat odd):
MahmoudUthman wrote:1-What is the proper use of see? right now I'm just using it to ignore losing captures & swaps in the quiescence (only in the case of non evasions),which causes a drop in the strength of the engine ,playing against it's former no SEE enabled version.
2-could this be caused by not handling pins in the SEE ? causing a winning capture to be reported as a losing one !
3-should I order the moves in the Quiescence instead thereby having all moves evaluated (if necessary) even if they are losing captures.
4-how much should SEE influence the result of the search if at all?
for example this is the result of the SEE/less /SEE search (which I think is somewhat odd):
Before SEE After SEE
position startpos position startpos
0 0
1 1
Key : 24B2E1A3752C36DF Key : 24B2E1A3752C36DF
searcht 1 searcht 1
BestMove e2e4 BestMove e2e4
Nodes 20 Nodes 20
QNodes 0 QNodes 0
time 0 ms time 0 ms
NPS 259076 NPS 443764
Thits 0 Thits 0
Tcuts 0 Tcuts 0
searcht 2 searcht 2
BestMove e2e4 BestMove e2e4
Nodes 40 Nodes 40
QNodes 9 QNodes 1
time 0 ms time 0 ms
NPS 383949 NPS 332903
Thits 0 Thits 0
Tcuts 0 Tcuts 0
searcht 3 searcht 3
BestMove d2d4 BestMove d2d4
Nodes 102 Nodes 102
QNodes 63 QNodes 42
time 0 ms time 0 ms
NPS 312303 NPS 261724
Thits 19 Thits 19
Tcuts 0 Tcuts 0
searcht 4 searcht 4
BestMove d2d4 BestMove d2d4
Nodes 741 Nodes 741
QNodes 953 QNodes 280
time 3 ms time 2 ms
NPS 542092 NPS 365215
Thits 122 Thits 122
Tcuts 61 Tcuts 61
searcht 5 searcht 5
BestMove e2e4 BestMove e2e4
Nodes 1962 Nodes 1945
QNodes 3343 QNodes 1913
time 11 ms time 10 ms
NPS 447258 NPS 354831
Thits 628 Thits 609
Tcuts 151 Tcuts 129
searcht 6 searcht 6
BestMove d2d4 BestMove d2d4
Nodes 13098 Nodes 13811
QNodes 25074 QNodes 13475
time 53 ms time 55 ms
NPS 714115 NPS 490508
Thits 3808 Thits 4129
Tcuts 2574 Tcuts 2598
searcht 7 searcht 7
BestMove e2e4 BestMove d2d4
Nodes 43514 Nodes 36756
QNodes 86928 QNodes 30973
time 207 ms time 181 ms
NPS 628006 NPS 372695
Thits 15502 Thits 14886
Tcuts 6635 Tcuts 5498
searcht 8 searcht 8
BestMove e2e4 BestMove d2d4
Nodes 253901 Nodes 272173
QNodes 660739 QNodes 324016
time 845 ms time 801 ms
NPS 1081398 NPS 743663
Thits 77382 Thits 91748
Tcuts 59590 Tcuts 63876
searcht 9 searcht 9
BestMove d2d4 BestMove d2d4
Nodes 904785 Nodes 666410
QNodes 1714159 QNodes 556006
time 3587 ms time 2541 ms
NPS 730049 NPS 481038
Thits 339307 Thits 272972
Tcuts 151224 Tcuts 108244
5-other than quiescence is it profitable to use see in other places for ordering or pruning given the extra time it incur ?
I don't understand your numbers. After 1 ply all looks well. 20 legal moves, no captures. But after ply 2, only 40 nodes TOTAL? That looks wrong. You have 20 legal moves for white, and after each white legal move you have 20 black moves. Looks like somehow you search one white move, then one black move, then back to the root, one white move, then one black move???
That's not minimax/alpha-beta or anything close to it.
You should make sure your SEE function is correct, within its design limitations.
I use MVV/LVA to order moves in quiescence, and then do SEE only just before the move is evaluated. You get reasonably good ordering that way and you avoid having to call SEE for every move, which is somewhat expensive, time-wise.
I also do SEE pruning (prune moves in the ply before quiescence with negative SEE - with a bunch of conditions: only non-PV, non-checking moves, etc.). This is pretty common now.
bob wrote:
I don't understand your numbers. After 1 ply all looks well. 20 legal moves, no captures. But after ply 2, only 40 nodes TOTAL? That looks wrong. You have 20 legal moves for white, and after each white legal move you have 20 black moves. Looks like somehow you search one white move, then one black move, then back to the root, one white move, then one black move???
That's not minimax/alpha-beta or anything close to it.
if (depthleft == 0) return q_search(alpha, beta);
,if it were before : search 2 NodesCount=96
-----------------------
I use MVV/LVA to order moves in quiescence too before using See to prune after that , but as I said it gives completely different results and decreases the strength of the engine .
bob wrote:
I don't understand your numbers. After 1 ply all looks well. 20 legal moves, no captures. But after ply 2, only 40 nodes TOTAL? That looks wrong. You have 20 legal moves for white, and after each white legal move you have 20 black moves. Looks like somehow you search one white move, then one black move, then back to the root, one white move, then one black move???
That's not minimax/alpha-beta or anything close to it.
if (depthleft == 0) return q_search(alpha, beta);
,if it were before : search 2 NodesCount=96
-----------------------
I use MVV/LVA to order moves in quiescence too before using See to prune after that , but as I said it gives completely different results and decreases the strength of the engine .
The traditional way of counting nodes is to increment the counter at the top of search AND quiesce. Or inside MakeMove(). You seem to be counting what is commonly called "a frontier node". Nodes where depth transitions to 0 and you change to quiescence rules.
For this to work (SEE) (a) it has to be reasonably correct and (b) you can't over-use it and slow your search down excessively. I just did a profile run with Crafty and SEE was less than 5% of total search time.