Odd/even iterations in the selektive search

[JensBNielsen]

8/5p2/5p2/8/k1p4P/8/6P1/4K3 w - - 0 0 am h4h5; play the king to the d-file

Dabbaba :
1 00:00 3 3 -0,53 h4h5 score: -53
1 00:00 19 19 -0,09 g2g4 score: -9
2 00:00 34 34 -0,62 g2g4 score: -62
3 00:00 186 186 -0,83 g2g4 score: -83
3 00:00 263 263 -0,16 e1d2 score: -16
4 00:00 695 695 -0,63 e1d2 score: -63
4 00:00 2.757 275.700 -0,19 e1d1 score: -19
5 00:00 4.910 491.000 -0,37 e1d1 score: -37
5 00:00 6.112 305.600 -0,19 h4h5 score: -19
6 00:00 14.114 201.628 -0,30 h4h5 score: -30
7 00:00 25.965 185.464 +0,21 h4h5 score: 21
8 00:02 357.753 243.369 +0,08 h4h5 score: 8
8 00:02 701.762 288.790 +7,82 e1d2 score: 782
9 00:03 755.781 272.845 -0,25 e1d2 score: -25
10 00:10 2.131.039 202.377 +8,20 e1d2 score: 820
10 00:11 3.396.748 307.955 +8,24 e1d1 score: 824
11 00:13 3.759.957 288.561 +0,30 e1d1 score: 30
12 00:26 5.345.127 201.323 +8,61 e1d1 score: 861


My program has a problem with the selektive search in the odd/even iterations.
In this position my program does not understand whites good position in iteration 9, 11...
In these odd iterations it evaluates the position before the selektive search and offer this score to black before black is trying some evt. selektive moves.

Sometimes this makes my program play bad moves.
Here it might have played h4-h5?

What should I do?

Should I store the information, that iteration 8 gave Ke1-d2 a score of +7,82 in the selektive search and not allow this score to be worse for Ke1-d2 in the next iteration?

Jens

PS. How do you get diagrams in your posts?
Do you have to upload it first (http://......)?

[krazyken]

all you have to do to diagram is put a [D] in front of the position

[D] 8/5p2/5p2/8/k1p4P/8/6P1/4K3 w - - 0 0 am h4h5

[bob]

8/5p2/5p2/8/k1p4P/8/6P1/4K3 w - - 0 0 am h4h5; play the king to the d-file

Dabbaba :
1 00:00 3 3 -0,53 h4h5 score: -53
1 00:00 19 19 -0,09 g2g4 score: -9
2 00:00 34 34 -0,62 g2g4 score: -62
3 00:00 186 186 -0,83 g2g4 score: -83
3 00:00 263 263 -0,16 e1d2 score: -16
4 00:00 695 695 -0,63 e1d2 score: -63
4 00:00 2.757 275.700 -0,19 e1d1 score: -19
5 00:00 4.910 491.000 -0,37 e1d1 score: -37
5 00:00 6.112 305.600 -0,19 h4h5 score: -19
6 00:00 14.114 201.628 -0,30 h4h5 score: -30
7 00:00 25.965 185.464 +0,21 h4h5 score: 21
8 00:02 357.753 243.369 +0,08 h4h5 score: 8
8 00:02 701.762 288.790 +7,82 e1d2 score: 782
9 00:03 755.781 272.845 -0,25 e1d2 score: -25
10 00:10 2.131.039 202.377 +8,20 e1d2 score: 820
10 00:11 3.396.748 307.955 +8,24 e1d1 score: 824
11 00:13 3.759.957 288.561 +0,30 e1d1 score: 30
12 00:26 5.345.127 201.323 +8,61 e1d1 score: 861


My program has a problem with the selektive search in the odd/even iterations.
In this position my program does not understand whites good position in iteration 9, 11...
In these odd iterations it evaluates the position before the selektive search and offer this score to black before black is trying some evt. selektive moves.

Sometimes this makes my program play bad moves.
Here it might have played h4-h5?

What should I do?

Should I store the information, that iteration 8 gave Ke1-d2 a score of +7,82 in the selektive search and not allow this score to be worse for Ke1-d2 in the next iteration?

Jens

PS. How do you get diagrams in your posts?
Do you have to upload it first (http://......)?

Looks to me like you have no quiescence search, so that you just terminate the search when depth==0 and do an eval. That won't work as you are seeing in your output.

[sje]

[D]8/5p2/5p2/8/k1p4P/8/6P1/4K3 w - - 0 1

Code: Select all

[-0.218/1/0.000/2/0] 1 g4
[-0.342/2/0.000/18/0] 1 g4 c3
[-0.260/3/0.000/66/0] 1 g4 f5 2 gxf5
[-0.126/3/0.000/104/0] 1 h5 f5 2 h6
[-0.302/4/0.000/265/0] 1 h5 c3 2 g4 c2
[-0.238/5/0.001/755/0] 1 h5 c3 2 g4 f5 3 gxf5
[-0.214/6/0.002/2,719/0] 1 h5 c3 2 h6 Kb4 3 h7 c2 4 Kd2
[-0.166/7/0.005/6,084/0] 1 h5 c3 2 h6 c2 3 Kd2 Kb3 4 h7 Kb2
[-0.466/8/0.011/16,541/0] 1 h5 c3 2 Kd1 Kb3 3 Kc1 f5 4 h6 Kc4
[-0.415/8/0.020/30,883/0] 1 Kd2 Kb3 2 Kc1 f5 3 h5
[-0.438/9/0.025/39,918/0] 1 Kd2 Kb3 2 Kc1 Kc3 3 h5 Kd3 4 g4 f5 5 gxf5
[-0.023/10/0.041/69,005/0] 1 Kd2 Kb3 2 Kc1 f5 3 h5 f4 4 h6 f3 5 gxf3 c3
[+0.157/11/0.060/102,004/0] 1 Kd2 Kb3 2 Kc1 f5 3 h5 f4 4 h6 f3 5 gxf3 c3 6 h7
[+0.657/12/0.090/150,613/0] 1 Kd2
[+7.129/12/0.121/200,519/0] 1 Kd2 Kb3 2 Kc1 c3 3 h5 Kc4 4 h6 Kd5 5 h7 Kd6 6 h8=Q Ke7 7 Kc2
[+7.629/13/0.155/256,919/0] 1 Kd2
[+7.779/13/0.187/310,510/0] 1 Kd2 Kb3 2 Kc1 f5 3 h5 f4 4 h6 f3 5 gxf3 Kc3 6 h7 Kd3 7 h8=Q
[+7.868/14/0.247/411,520/0] 1 Kd2 Kb3 2 Kc1 f5 3 h5 f4 4 h6 f3 5 gxf3 Kc3 6 h7 Kb3 7 h8=Q c3 8 Qb8+ Kc4
[+8.261/15/0.410/663,809/0] 1 Kd2 Kb3 2 Kc1 Kc3 3 h5 Kd3 4 h6 Ke3 5 h7 Kf2 6 h8=Q Kxg2 7 Qxf6 Kg3 8 Kc2 Kg4 9 Qxf7
[+8.346/16/0.702/1,111,184/0] 1 Kd2 Kb3 2 Kc1 Kc3 3 h5 f5 4 h6 Kd4 5 h7 f6 6 h8=Q Ke5 7 Qb8+ Ke4 8 Qb5 Kf4 9 Qxc4+
[+8.560/17/1.627/2,413,388/0] 1 Kd2 Kb3 2 Kc1 Kc3 3 h5 f5 4 h6 Kd4 5 h7 Kd5 6 h8=Q Ke6 7 Qc8+ Kf6 8 Qxc4 Kg6 9 Kd2 Kf6 10 Qc3+
[+8.592/18/4.072/5,808,504/0] 1 Kd2 Kb3 2 Kc1 Kc3 3 h5 f5 4 h6 Kd4 5 h7 f6 6 h8=Q Ke5 7 Qc8 f4 8 Qc5+ Ke4 9 Qxc4+ Ke5 10 Qc5+ Ke4 11 Qc2+ Ke5

8/5p2/5p2/8/k1p4P/8/6P1/4K3 w - - 0 1 acd 18; acn 5808504; cc 4:53.950 5:00.000; nef 1.42499e+06; nep 7.01759e-07; nuf 1.42616e+06; nup 7.01186e-07; pes +8.592; pv Kd2 Kb3 Kc1 Kc3 h5 f5 h6 Kd4 h7 f6 h8=Q Ke5 Qc8 f4 Qc5+ Ke4 Qxc4+ Ke5 Qc5+ Ke4 Qc2+ Ke5; te 4.076; tu 4.072;

[JensBNielsen]

Looks to me like you have no quiescence search, so that you just terminate the search when depth==0 and do an eval. That won't work as you are seeing in your output.

Thanks. I have now made a better quiescence search (see below).

It is still slow; though, as I try all captures.
I must change it to only try sufficient recaptures where it is relevant.

But how do you determine when it is a sufficient recapture?
Is it when the materiel balance matches the score achieved in the previous iteration....?




Dabbaba:
1 00:00 164 164 -0,53 h4h5 score: -53 v=-53 pawn=47 mat=-100 n=164 time=0.00
1 00:00 191 191 -0,42 g2g4 score: -42 v=-45 pawn=55 mat=-100 n=191 time=0.00
2 00:00 300 300 -0,43 g2g4 score: -43 v=-282 pawn=-182 mat=-100 n=300 time=0.00
2 00:00 1.884 1.884 -0,21 h4h5 score: -21 v=-53 pawn=47 mat=-100 n=1884 time=0.00
3 00:00 8.602 8.602 +3,03 h4h5 score: 303 v=-42 pawn=58 mat=-100 n=8602 time=0.00
4 00:00 27.084 677.100 -0,47 h4h5 score: -47 v=-76 pawn=24 mat=-100 n=27084 time=0.04 N/S=677100
4 00:00 29.112 727.800 -0,37 e1d2 score: -37 v=-61 pawn=32 king=7 mat=-100 n=29112 time=0.04 N/S=727800
5 00:00 42.826 611.800 -0,60 e1d2 score: -60 v=9 pawn=102 king=7 mat=-100 n=42826 time=0.07 N/S=611800
5 00:00 62.215 777.687 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=62215 time=0.08 N/S=777688
6 00:00 90.340 694.923 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=90340 time=0.13 N/S=694923
6 00:00 110.206 688.787 0,00 e1d1 score: 0 v=-97 pawn=3 mat=-100 n=110206 time=0.16 N/S=688788
7 00:00 163.951 655.804 +7,36 e1d1 score: 736 v=-102 pawn=-2 mat=-100 n=163951 time=0.25 N/S=655804
8 00:00 231.388 642.744 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=231388 time=0.36 N/S=642744
9 00:00 428.595 621.152 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=428595 time=0.69 N/S=621152
10 00:02 909.692 645.171 +7,43 e1d1 score: 743 v=-97 pawn=3 mat=-100 n=909692 time=1.41 N/S=645172

1 00:00 5 5 +0,02 (hash: write=87259 nowrite=1493278 pre-va=1031303 pre-va-hit=691679
1 00:00 5 5 +0,02 (hash: error=0 nofinal(cut-off!)=8824 read=1394625 read_ok=719136 read_ok_final(same position met again)=1216
1 00:00 5 5 +0,02 (hash-elementer: max=524287 used=47666 used-pct=9.1 - VERSION 2.08 JA-Pelle Date 18-07-2009
1 00:00 5 5 +0,02 e1d1 a4b3 d1c1 f6f5 g2g3 b3c3 h4h5 c3d4 h5h6 d4e4 h6h7 f5f4 g3f4 f7f5

[Uri Blass]

Looks to me like you have no quiescence search, so that you just terminate the search when depth==0 and do an eval. That won't work as you are seeing in your output.

Thanks. I have now made a better quiescence search (see below).

It is still slow; though, as I try all captures.
I must change it to only try sufficient recaptures where it is relevant.

But how do you determine when it is a sufficient recapture?
Is it when the materiel balance matches the score achieved in the previous iteration....?




Dabbaba:
1 00:00 164 164 -0,53 h4h5 score: -53 v=-53 pawn=47 mat=-100 n=164 time=0.00
1 00:00 191 191 -0,42 g2g4 score: -42 v=-45 pawn=55 mat=-100 n=191 time=0.00
2 00:00 300 300 -0,43 g2g4 score: -43 v=-282 pawn=-182 mat=-100 n=300 time=0.00
2 00:00 1.884 1.884 -0,21 h4h5 score: -21 v=-53 pawn=47 mat=-100 n=1884 time=0.00
3 00:00 8.602 8.602 +3,03 h4h5 score: 303 v=-42 pawn=58 mat=-100 n=8602 time=0.00
4 00:00 27.084 677.100 -0,47 h4h5 score: -47 v=-76 pawn=24 mat=-100 n=27084 time=0.04 N/S=677100
4 00:00 29.112 727.800 -0,37 e1d2 score: -37 v=-61 pawn=32 king=7 mat=-100 n=29112 time=0.04 N/S=727800
5 00:00 42.826 611.800 -0,60 e1d2 score: -60 v=9 pawn=102 king=7 mat=-100 n=42826 time=0.07 N/S=611800
5 00:00 62.215 777.687 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=62215 time=0.08 N/S=777688
6 00:00 90.340 694.923 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=90340 time=0.13 N/S=694923
6 00:00 110.206 688.787 0,00 e1d1 score: 0 v=-97 pawn=3 mat=-100 n=110206 time=0.16 N/S=688788
7 00:00 163.951 655.804 +7,36 e1d1 score: 736 v=-102 pawn=-2 mat=-100 n=163951 time=0.25 N/S=655804
8 00:00 231.388 642.744 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=231388 time=0.36 N/S=642744
9 00:00 428.595 621.152 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=428595 time=0.69 N/S=621152
10 00:02 909.692 645.171 +7,43 e1d1 score: 743 v=-97 pawn=3 mat=-100 n=909692 time=1.41 N/S=645172

1 00:00 5 5 +0,02 (hash: write=87259 nowrite=1493278 pre-va=1031303 pre-va-hit=691679
1 00:00 5 5 +0,02 (hash: error=0 nofinal(cut-off!)=8824 read=1394625 read_ok=719136 read_ok_final(same position met again)=1216
1 00:00 5 5 +0,02 (hash-elementer: max=524287 used=47666 used-pct=9.1 - VERSION 2.08 JA-Pelle Date 18-07-2009
1 00:00 5 5 +0,02 e1d1 a4b3 d1c1 f6f5 g2g3 b3c3 h4h5 c3d4 h5h6 d4e4 h6h7 f5f4 g3f4 f7f5

I do not understand how do you get more than 100 nodes at depth 1 because no moves of white allow promotion or capture by black.

Uri

[bob]

Looks to me like you have no quiescence search, so that you just terminate the search when depth==0 and do an eval. That won't work as you are seeing in your output.

Thanks. I have now made a better quiescence search (see below).

It is still slow; though, as I try all captures.
I must change it to only try sufficient recaptures where it is relevant.

But how do you determine when it is a sufficient recapture?
Is it when the materiel balance matches the score achieved in the previous iteration....?

What I do is ask the question "will this capture (which means material gain) bring the score back to at least the alpha bound score?" If the answer is yes, then I search it. Now how I answer the "will this capture...." question is a bit more complex as I use what is called a SEE or Static Exchange Evaluator to evaluate captures on a single square to see if the initial capture wins or loses material. I use this score added to the current real material score and compare that to the current alpha bound. if SEE(move) + MaterialBalance < alpha, forget searching that move.

Dabbaba:
1 00:00 164 164 -0,53 h4h5 score: -53 v=-53 pawn=47 mat=-100 n=164 time=0.00
1 00:00 191 191 -0,42 g2g4 score: -42 v=-45 pawn=55 mat=-100 n=191 time=0.00
2 00:00 300 300 -0,43 g2g4 score: -43 v=-282 pawn=-182 mat=-100 n=300 time=0.00
2 00:00 1.884 1.884 -0,21 h4h5 score: -21 v=-53 pawn=47 mat=-100 n=1884 time=0.00
3 00:00 8.602 8.602 +3,03 h4h5 score: 303 v=-42 pawn=58 mat=-100 n=8602 time=0.00
4 00:00 27.084 677.100 -0,47 h4h5 score: -47 v=-76 pawn=24 mat=-100 n=27084 time=0.04 N/S=677100
4 00:00 29.112 727.800 -0,37 e1d2 score: -37 v=-61 pawn=32 king=7 mat=-100 n=29112 time=0.04 N/S=727800
5 00:00 42.826 611.800 -0,60 e1d2 score: -60 v=9 pawn=102 king=7 mat=-100 n=42826 time=0.07 N/S=611800
5 00:00 62.215 777.687 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=62215 time=0.08 N/S=777688
6 00:00 90.340 694.923 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=90340 time=0.13 N/S=694923
6 00:00 110.206 688.787 0,00 e1d1 score: 0 v=-97 pawn=3 mat=-100 n=110206 time=0.16 N/S=688788
7 00:00 163.951 655.804 +7,36 e1d1 score: 736 v=-102 pawn=-2 mat=-100 n=163951 time=0.25 N/S=655804
8 00:00 231.388 642.744 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=231388 time=0.36 N/S=642744
9 00:00 428.595 621.152 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=428595 time=0.69 N/S=621152
10 00:02 909.692 645.171 +7,43 e1d1 score: 743 v=-97 pawn=3 mat=-100 n=909692 time=1.41 N/S=645172

1 00:00 5 5 +0,02 (hash: write=87259 nowrite=1493278 pre-va=1031303 pre-va-hit=691679
1 00:00 5 5 +0,02 (hash: error=0 nofinal(cut-off!)=8824 read=1394625 read_ok=719136 read_ok_final(same position met again)=1216
1 00:00 5 5 +0,02 (hash-elementer: max=524287 used=47666 used-pct=9.1 - VERSION 2.08 JA-Pelle Date 18-07-2009
1 00:00 5 5 +0,02 e1d1 a4b3 d1c1 f6f5 g2g3 b3c3 h4h5 c3d4 h5h6 d4e4 h6h7 f5f4 g3f4 f7f5

[diep]

Looks to me like you have no quiescence search, so that you just terminate the search when depth==0 and do an eval. That won't work as you are seeing in your output.

Thanks. I have now made a better quiescence search (see below).

It is still slow; though, as I try all captures.
I must change it to only try sufficient recaptures where it is relevant.

But how do you determine when it is a sufficient recapture?
Is it when the materiel balance matches the score achieved in the previous iteration....?

What I do is ask the question "will this capture (which means material gain) bring the score back to at least the alpha bound score?" If the answer is yes, then I search it. Now how I answer the "will this capture...." question is a bit more complex as I use what is called a SEE or Static Exchange Evaluator to evaluate captures on a single square to see if the initial capture wins or loses material. I use this score added to the current real material score and compare that to the current alpha bound. if SEE(move) + MaterialBalance < alpha, forget searching that move.

Dabbaba:
1 00:00 164 164 -0,53 h4h5 score: -53 v=-53 pawn=47 mat=-100 n=164 time=0.00
1 00:00 191 191 -0,42 g2g4 score: -42 v=-45 pawn=55 mat=-100 n=191 time=0.00
2 00:00 300 300 -0,43 g2g4 score: -43 v=-282 pawn=-182 mat=-100 n=300 time=0.00
2 00:00 1.884 1.884 -0,21 h4h5 score: -21 v=-53 pawn=47 mat=-100 n=1884 time=0.00
3 00:00 8.602 8.602 +3,03 h4h5 score: 303 v=-42 pawn=58 mat=-100 n=8602 time=0.00
4 00:00 27.084 677.100 -0,47 h4h5 score: -47 v=-76 pawn=24 mat=-100 n=27084 time=0.04 N/S=677100
4 00:00 29.112 727.800 -0,37 e1d2 score: -37 v=-61 pawn=32 king=7 mat=-100 n=29112 time=0.04 N/S=727800
5 00:00 42.826 611.800 -0,60 e1d2 score: -60 v=9 pawn=102 king=7 mat=-100 n=42826 time=0.07 N/S=611800
5 00:00 62.215 777.687 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=62215 time=0.08 N/S=777688
6 00:00 90.340 694.923 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=90340 time=0.13 N/S=694923
6 00:00 110.206 688.787 0,00 e1d1 score: 0 v=-97 pawn=3 mat=-100 n=110206 time=0.16 N/S=688788
7 00:00 163.951 655.804 +7,36 e1d1 score: 736 v=-102 pawn=-2 mat=-100 n=163951 time=0.25 N/S=655804
8 00:00 231.388 642.744 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=231388 time=0.36 N/S=642744
9 00:00 428.595 621.152 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=428595 time=0.69 N/S=621152
10 00:02 909.692 645.171 +7,43 e1d1 score: 743 v=-97 pawn=3 mat=-100 n=909692 time=1.41 N/S=645172

1 00:00 5 5 +0,02 (hash: write=87259 nowrite=1493278 pre-va=1031303 pre-va-hit=691679
1 00:00 5 5 +0,02 (hash: error=0 nofinal(cut-off!)=8824 read=1394625 read_ok=719136 read_ok_final(same position met again)=1216
1 00:00 5 5 +0,02 (hash-elementer: max=524287 used=47666 used-pct=9.1 - VERSION 2.08 JA-Pelle Date 18-07-2009
1 00:00 5 5 +0,02 e1d1 a4b3 d1c1 f6f5 g2g3 b3c3 h4h5 c3d4 h5h6 d4e4 h6h7 f5f4 g3f4 f7f5

Hi Bob,

Of course at the level that Jens Nielsen needs to fix his program for we both agree with respect to the program. Fixing qsearch is really important. Print verbose which moves you try Jens, note it could also be other bugs in search, like inconsequent extensions.

Do you extend some things when above beta instead of when above alpha? Or does a research work crappy?

However Bob, we disagree with the definition of what a qsearch should find. Your assumption of qsearch assumes implicitly futility. Futility assumes you can PREDICT how good a move in qsearch that gets tried will change score in advance.

That's the chicken and egg problem of course.

That's a very instable manner of searching positions, as our alpha when researching will be different, hence it implies that our hashtable a ply before would already have given a lowerbound whereas the position is true or upperbound.

I would want to redefine it to: "we want to search to a quiet position and thereby try moves that dramatically change the score. And if we are so lucky that this improves our alpha, then we are happy that we searched this move, yet we couldn't predict it in advance of course. In Diep i make a very strict and small selection on which moves to try, but alpha nor beta is part of that consideration.

Now i realize this is different in some high nps beancounters, as i used futility in my 2.5 mln nps search also, but in Diep i definitely invest system time in figuring out which moves to try or not try, but it is all based upon chessknowledge, not alpha nor beta (of course they INFLUENCE the score outcome, as we cutoff when above beta).

Additionally in Diep i measured how many nodes tried in qsearch were not above alpha (so basically wasted and potentially what you'd save out with futility). That was less than 5% even in tactical middlegame positions.

Obviously i did do that test as using futility saved out just very few % in search time, whereas it missed really a lot of tactics, not to mention positionally.

So i'd say: better search a move too much in qsearch than too little.
and of course in diep i have to improve that, that's obvious. Hopefully ths is not similar to end of 90s where Bob promoted to me the idea of implementing DTS. And i did. Whereas Bob didn't use it in Crafty. Nowadays Diep isn't using DTS but just like crafty a cpu that is searching 'by accident' takes a look whether there is some cores left to split. So i hope i sincerely hope my "you ought to do it in this manner", is also the philosophy i implement a tad more myself as well.

I know the philosophy in crafty here is the opposite one, it always used to do ultra little in qsearch, though rumours reached me latest crafty versions also try a check sometimes. Can you confirm that Bob, that what you promote here soon might no longer be reality?

Now there is no absolute truth here what works better. Because trying really a LOT more moves in qsearch definitely reduces the number of nodes you have to search in the main search, but of course increases the overhead that qsearch eats. On what side of the balance you go for, it is a choice, yet i wanted to make it clear that this choice is there

p.s. don't confuse all this with forward pruning in main search, that's an entire different topic IMHO from qsearch, though a discussion on that is quite relevant it seems.

[bob]

Looks to me like you have no quiescence search, so that you just terminate the search when depth==0 and do an eval. That won't work as you are seeing in your output.

Thanks. I have now made a better quiescence search (see below).

It is still slow; though, as I try all captures.
I must change it to only try sufficient recaptures where it is relevant.

But how do you determine when it is a sufficient recapture?
Is it when the materiel balance matches the score achieved in the previous iteration....?

What I do is ask the question "will this capture (which means material gain) bring the score back to at least the alpha bound score?" If the answer is yes, then I search it. Now how I answer the "will this capture...." question is a bit more complex as I use what is called a SEE or Static Exchange Evaluator to evaluate captures on a single square to see if the initial capture wins or loses material. I use this score added to the current real material score and compare that to the current alpha bound. if SEE(move) + MaterialBalance < alpha, forget searching that move.

Dabbaba:
1 00:00 164 164 -0,53 h4h5 score: -53 v=-53 pawn=47 mat=-100 n=164 time=0.00
1 00:00 191 191 -0,42 g2g4 score: -42 v=-45 pawn=55 mat=-100 n=191 time=0.00
2 00:00 300 300 -0,43 g2g4 score: -43 v=-282 pawn=-182 mat=-100 n=300 time=0.00
2 00:00 1.884 1.884 -0,21 h4h5 score: -21 v=-53 pawn=47 mat=-100 n=1884 time=0.00
3 00:00 8.602 8.602 +3,03 h4h5 score: 303 v=-42 pawn=58 mat=-100 n=8602 time=0.00
4 00:00 27.084 677.100 -0,47 h4h5 score: -47 v=-76 pawn=24 mat=-100 n=27084 time=0.04 N/S=677100
4 00:00 29.112 727.800 -0,37 e1d2 score: -37 v=-61 pawn=32 king=7 mat=-100 n=29112 time=0.04 N/S=727800
5 00:00 42.826 611.800 -0,60 e1d2 score: -60 v=9 pawn=102 king=7 mat=-100 n=42826 time=0.07 N/S=611800
5 00:00 62.215 777.687 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=62215 time=0.08 N/S=777688
6 00:00 90.340 694.923 -0,57 h4h5 score: -57 v=-76 pawn=24 mat=-100 n=90340 time=0.13 N/S=694923
6 00:00 110.206 688.787 0,00 e1d1 score: 0 v=-97 pawn=3 mat=-100 n=110206 time=0.16 N/S=688788
7 00:00 163.951 655.804 +7,36 e1d1 score: 736 v=-102 pawn=-2 mat=-100 n=163951 time=0.25 N/S=655804
8 00:00 231.388 642.744 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=231388 time=0.36 N/S=642744
9 00:00 428.595 621.152 +7,36 e1d1 score: 736 v=-97 pawn=3 mat=-100 n=428595 time=0.69 N/S=621152
10 00:02 909.692 645.171 +7,43 e1d1 score: 743 v=-97 pawn=3 mat=-100 n=909692 time=1.41 N/S=645172

1 00:00 5 5 +0,02 (hash: write=87259 nowrite=1493278 pre-va=1031303 pre-va-hit=691679
1 00:00 5 5 +0,02 (hash: error=0 nofinal(cut-off!)=8824 read=1394625 read_ok=719136 read_ok_final(same position met again)=1216
1 00:00 5 5 +0,02 (hash-elementer: max=524287 used=47666 used-pct=9.1 - VERSION 2.08 JA-Pelle Date 18-07-2009
1 00:00 5 5 +0,02 e1d1 a4b3 d1c1 f6f5 g2g3 b3c3 h4h5 c3d4 h5h6 d4e4 h6h7 f5f4 g3f4 f7f5

Hi Bob,

Of course at the level that Jens Nielsen needs to fix his program for we both agree with respect to the program. Fixing qsearch is really important. Print verbose which moves you try Jens, note it could also be other bugs in search, like inconsequent extensions.

Do you extend some things when above beta instead of when above alpha? Or does a research work crappy?

However Bob, we disagree with the definition of what a qsearch should find. Your assumption of qsearch assumes implicitly futility. Futility assumes you can PREDICT how good a move in qsearch that gets tried will change score in advance.

That's the chicken and egg problem of course.

That's a very instable manner of searching positions, as our alpha when researching will be different, hence it implies that our hashtable a ply before would already have given a lowerbound whereas the position is true or upperbound.

I would want to redefine it to: "we want to search to a quiet position and thereby try moves that dramatically change the score. And if we are so lucky that this improves our alpha, then we are happy that we searched this move, yet we couldn't predict it in advance of course. In Diep i make a very strict and small selection on which moves to try, but alpha nor beta is part of that consideration.

Now i realize this is different in some high nps beancounters, as i used futility in my 2.5 mln nps search also, but in Diep i definitely invest system time in figuring out which moves to try or not try, but it is all based upon chessknowledge, not alpha nor beta (of course they INFLUENCE the score outcome, as we cutoff when above beta).

Additionally in Diep i measured how many nodes tried in qsearch were not above alpha (so basically wasted and potentially what you'd save out with futility). That was less than 5% even in tactical middlegame positions.

Obviously i did do that test as using futility saved out just very few % in search time, whereas it missed really a lot of tactics, not to mention positionally.

So i'd say: better search a move too much in qsearch than too little.
and of course in diep i have to improve that, that's obvious. Hopefully ths is not similar to end of 90s where Bob promoted to me the idea of implementing DTS. And i did. Whereas Bob didn't use it in Crafty. Nowadays Diep isn't using DTS but just like crafty a cpu that is searching 'by accident' takes a look whether there is some cores left to split. So i hope i sincerely hope my "you ought to do it in this manner", is also the philosophy i implement a tad more myself as well.

I know the philosophy in crafty here is the opposite one, it always used to do ultra little in qsearch, though rumours reached me latest crafty versions also try a check sometimes. Can you confirm that Bob, that what you promote here soon might no longer be reality?

Now there is no absolute truth here what works better. Because trying really a LOT more moves in qsearch definitely reduces the number of nodes you have to search in the main search, but of course increases the overhead that qsearch eats. On what side of the balance you go for, it is a choice, yet i wanted to make it clear that this choice is there

p.s. don't confuse all this with forward pruning in main search, that's an entire different topic IMHO from qsearch, though a discussion on that is quite relevant it seems.

My point was a quick explanation to answer his question. QxP is not going to help if I am a rook down. Or a piece down. Or if the pawn is defended... That's all I was trying to explain.

[JensBNielsen]

I do not understand how do you get more than 100 nodes at depth 1 because no moves of white allow promotion or capture by black.

Uri

When white moves his king to d2 black can check with his pawn.