Vescovi-Shaked, Mermaid Beach Club 1997

Discussion of anything and everything relating to chess playing software and machines.

Moderator: Ras

User avatar
Eelco de Groot
Posts: 4676
Joined: Sun Mar 12, 2006 2:40 am
Full name:   Eelco de Groot

Re: Vescovi-Shaked, Mermaid Beach Club 1997

Post by Eelco de Groot »

Dann Corbit wrote:
MattieShoes wrote:If you're interested in what a crap engine thinks... My engine found a6 on ply 2, lost it on ply 10 for Nd3, then went back to a6 on ply 13 (35 seconds or so). It stayed with a6 through ply 16, at which point I killed the analysis :-)
Most engines follow a similar pattern, including the titans.
Well, Blueberry in its latest build is still pondering the excellence of 1. a6 after 1246 minutes without showing any haste of actually playing the @#$$ move so I can count the solution... It started of well compared to earlier builds, quickly found 1.Nd3 and only at depth eight it started thinking that maybe this 1.a6 thing was better. And then the long wait begins...

[d]6r1/1pp2knQ/3p1r2/P2Pq3/2P1BpR1/4bPp1/R5K1/4N3 w - -

Engine: Blueberry Beta 4 DM70 NoSE Build 444 (128 MB)
by F. Letouzey, T. Gaksch, E. de Groot

1/16 0:00 -5.05 1.Rxg7+ Rxg7 2.Nd3 (1.328)

1/16 0:00 -2.65 1.Nc2 (1.330)

1/16 0:00 -2.27 1.Nd3 (1.332)

1/16 0:00 -1.23 1.Kf1 (2.010)

2/37 0:00 -0.90 1.Kf1 Kf8 2.Nd3 Qc3 (208.831)

2/39 0:02 -0.47 1.Nd3 Qc3 2.Rb2 b6 3.Re2 Qd4 4.Bg6+ Kf8
5.axb6 Qxb6 (1.154.593) 505

2/39 0:04 0.00 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ke2 Qa2+ 6.Kf1 (2.313.066) 493

2/46 0:09 +0.35 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qc2+
4.Kf1 Qd1+ 5.Ne1 Qc1 6.Bg6+ Rxg6
7.Qxg6+ Ke7 (5.053.220) 518

2/46 0:09 +0.35 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qc2+
4.Kf1 Qd1+ 5.Ne1 Qc1 6.Bg6+ Rxg6
7.Qxg6+ Ke7 (5.053.220) 518

3/59 4:20 +1.27 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qxc2+ 5.Bxc2 Kf8 6.Bb3 Rd6
7.Rg5 Bd4 (151.673.016) 583

4/59 5:40 +1.59 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 g2+ 6.Kxg2 Qxa5
7.Kh3 Bf2 (196.933.654) 577

5/59 10:54 +1.59 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 g2+ 6.Kxg2 Qxa5
7.Kh3 Bf2 (380.505.898) 581

6/60 12:00 +1.59 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 g2+ 6.Kxg2 Qxa5
7.Kh3 Bf2 (414.140.340) 575

7/60 21:20 +1.72 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 g2+ 6.Kxg2 Qxa5
7.Bg6+ Rxg6 8.Rxg6 Bd4 (588.132.726) 459

8/60 43:10 +0.94 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qc5 5.Rxc5 Bxc5 6.Rg5 Bd4
7.Bg6+ Kf8 (983.744.516) 379

Close to 21 hours now and still no 1.a6. I even have switched off the singular extensions, that is, NoSE, no singular extensions in PV nodes. Rybka is making much fuss about showing singular extensions in PV nodes so I thought there must be something very wrong with that, I am now only extending singular moves in all the other non-PV nodes :lol: I tried that before and actually it was very hard to see a position where it made any difference so I thought I had made a mistake again in the code somewhere. But now I'm not so sure, I think it has to do with beta cut-offs but it is probably better not to do much theorizing about it as I have no idea it will actually work as planned. So far I would like to have amazing results like Glaurung, Moneypenny and Rybka 3 :)

This is Rybka 2.2n2 at 50%, it is clearly not as fast as Rybka 3 and Blueberry seemed to keep up for a while;

Rybka 2.2n2 at 50% CPU

6r1/1pp2knQ/3p1r2/P2Pq3/2P1BpR1/4bPp1/R5K1/4N3 w - -

Engine: Rybka 2.2n2 mp 32-bit PVtips5menbases (Athlon 2009 MHZ, 128 MB)
by Vasik Rajlich

2.00 0:00 -0.29 1.a6 bxa6 2.Nc2 Kf8 3.Rxa6 (798) 0

2.00 0:00 -0.25 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qd2+
4.Kf1 (972) 1

3.00 0:01 -0.25 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qd2+ (1.306) 1

3.00 0:01 +0.07 1.a6 bxa6 2.Nc2 Qc3 3.Nxe3 fxe3 (1.843) 1

4.00 0:01 +0.14 1.a6 bxa6 2.Rxa6 Qb2+ 3.Nc2 Qb7
4.Ra1 Bc5 (2.844) 2

5.00 0:01 +0.10 1.a6 bxa6 2.Rxa6 Qb2+ 3.Nc2 Qb7
4.Ra1 Bc5 5.Bg6+ Kf8 (3.578) 3

6.00 0:01 +0.08 1.a6 bxa6 2.Rxa6 Qb2+ 3.Nc2 Qb7
4.Ra1 Bf2 5.Bg6+ Kf8 6.Be8 (5.793) 4

7.00 0:01 0.00 1.a6 bxa6 2.Rxa6 Qb2+ 3.Nc2 Qc1
4.Nxe3 Qd2+ 5.Kh1 Qe1+ 6.Kg2 Qd2+ (15.219) 10

7.00 0:01 +0.21 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Rb2 Qa8 5.c5 Bd4 6.Re2 (22.787) 13

8.00 0:02 +0.27 1.Nd3 Qd4 2.Rb2 Qa7 3.c5 Kf8 4.cxd6 Rxd6
5.Nxf4 Bd4 6.Re2 (36.306) 17

9.00 0:03 +0.21 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Rb2 Qa8 5.c5 Qa7 6.Rg6 Bd4 7.Rxf6+ Bxf6
8.Bg6+ Kf8 (81.350) 27

10.01 0:03 +0.59 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qxc2+ 5.Bxc2 Kf8 6.Rg5 Bd4
7.Bd3 Rd6 8.Be4 Kf7 (127.518) 33

11.01 0:05 +0.86 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qxc2+ 5.Bxc2 Kf8 6.Rg5 Bd4
7.d6 cxd6 8.Bb3 Rf7 9.Bxf7 (184.405) 36

12.01 0:07 +0.92 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qxc2+ 5.Bxc2 Kf8 6.Rg5 Bd4
7.d6 cxd6 8.Bb3 Rf7 9.Bxf7 Kxf7
10.Rf5+ Ke7 11.Qxg8 (309.961) 41

13.01 0:12 +1.08 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 b5 5.Rxc4 bxc4 6.Rg5 Kf8 7.Qh4 Kf7
8.Qh3 Rd6 9.Rxe5 c3 (555.473) 45

14.01 0:28 +0.91 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Bb6 5.Rb8 g2+ 6.Rxg2 Qxg2+
7.Kxg2 Rxb8 8.Nb4 Ba5 9.Nc6 Rb2+
10.Kh3 Bc3 11.Bc2 (1.368.213) 49

15.01 0:40 +0.71 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Bb6 5.Rb8 g2+ 6.Rxg2 Qxg2+ (2.078.335) 52

16.01 1:05 +0.98 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Bb6 5.Rb8 g2+ 6.Rxg2 Qxg2+ (3.490.366) 54

17.01 1:57 +0.97 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Bb6 5.Rb8 g2+ 6.Rxg2 Qxg2+
7.Kxg2 Rxb8 8.Nb4 Bd4 9.Nc6 Rb2+
10.Bc2 Bc3 11.Kh3 (6.423.207) 56

18.01 4:13 +0.97 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Bb6 5.Rb8 g2+ 6.Rxg2 Qxg2+
7.Kxg2 Rxb8 8.Nb4 Bd4 9.Nc6 Rb2+
10.Bc2 Bc3 (13.953.787) 56

19.01 10:46 +0.84 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Bb6 5.Rb8 g2+ 6.Rxg2 Qxg2+
7.Kxg2 Rxb8 8.Nb4 Bd4 9.Nc6 Rb2+
10.Bc2 Bc3 (36.374.597) 57

19.02 19:07 +2.48 1.a6 bxa6 2.Nd3 Qc3 3.Bg6+ Kf8 4.Bh5 Qxd3
5.Qxd3 Nxh5 6.Rh4 Ng7 7.Rxa6 (60.865.784) 54

20.01 25:25 +2.48 1.a6 bxa6 2.Nd3 Qc3 3.Bg6+ Kf8 4.Bh5 Qxd3
5.Qxd3 Nxh5 6.Rh4 Ng7 7.Rxa6 (77.831.620) 52

21.01 47:26 +3.12 1.a6 bxa6 2.Nd3 Qxe4 3.Qxe4 Rh8
4.Nxf4 Rh2+ 5.Kf1 Bxf4 6.Rxa6 Be5
7.Ra7 Rf2+ (143.189.509) 51

22.01 68:30 +3.12 1.a6 bxa6 2.Nd3 Qxe4 3.Qxe4 Rh8
4.Nxf4 Rh2+ 5.Kf1 Bxf4 6.Rxa6 Be5
7.Ra7 Rf2+ (206.299.418) 51

23.01 110:01 +3.12 1.a6 bxa6 2.Nd3 Qxe4 3.Qxe4 Rh8
4.Nxf4 Rh2+ 5.Kf1 Bxf4 6.Rxa6 Be5
7.Ra7 Rf2+ (329.009.285) 51

24.01 193:12 +3.12 1.a6 bxa6 2.Nd3 Qxe4 3.Qxe4 Rh8
4.Nxf4 Rh2+ 5.Kf1 Bxf4 6.Rxa6 Be5
7.Ra7 Rf2+ (575.140.296) 50

25.01 359:59 +3.12 1.a6 bxa6 2.Nd3 Qxe4 3.Qxe4 Rh8
4.Nxf4 Rh2+ 5.Kf1 Bxf4 6.Rxa6 Be5
7.Ra7 Rf2+ (1.080.510.151) 51

best move: a5-a6 time: 386:23.312 min n/s: 1184.436.341 nodes: 1.184.436.341

Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
Top
User avatar
Eelco de Groot
Posts: 4676
Joined: Sun Mar 12, 2006 2:40 am
Full name:   Eelco de Groot

Re: Vescovi-Shaked, Mermaid Beach Club 1997

Post by Eelco de Groot »

Finally a little bit better result and Blueberry can find a6 in reasonable time! I must say this is all just heavily tuned for one position only but still this is better than what I had:

best move: Ne1-d3 time: 1321:15.922 min n/s: 447.929 CPU 100.0% n/s(1CPU): 447.929 nodes: 35.509.880.000

Probably I still can't reach six plies after having found 1.a6 but there must be a way of fixing that. I hope that this actually might lead to real search improvements one day. Still it is not often Blueberry finds something faster than Rybka 2.2n2 :)


[d]6r1/1pp2knQ/3p1r2/P2Pq3/2P1BpR1/4bPp1/R5K1/4N3 w - -

Engine: Blueberry Beta 4 DM70 NoSE Build 448 (128 MB)
by F. Letouzey, T. Gaksch, E. de Groot

1/16 0:00 -5.05 1.Rxg7+ Rxg7 2.Nd3 (1.328)

1/16 0:00 -2.65 1.Nc2 (1.330)

1/16 0:00 -2.27 1.Nd3 (1.332)

1/16 0:00 -1.23 1.Kf1 (2.010)

2/37 0:00 -0.83 1.Kf1 Kf8 2.Nd3 (199.867)

2/37 0:00 -0.53 1.Bg6+ Kf8 2.Nd3 Qd4 3.Rb2 b6 4.Kh3 Qxc4
5.axb6 Bxb6 (350.083)

2/38 0:01 -0.63 1.Bg6+ Kf8 2.Nd3 Qd4 3.Rb2 Qxc4
4.Rxb7 Ne8 5.Kh1 Qxd5 (584.107) 450

2/38 0:02 -0.49 1.Nd3 Qc3 2.Bg6+ Kf8 3.Rb2 Qxc4
4.Rxb7 Ne8 (1.343.068) 440

2/41 0:05 0.00 1.Nd3 Qd4 2.Rb2 b6 3.Bg6+ Kf8 4.axb6 cxb6
5.Ra2 Ne8 6.Qh6+ Ke7 7.Qh7+ Kf8 (2.421.140) 482

2/42 0:10 +0.35 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 Qa5 6.Bg6+ Rxg6
7.Rxg6 (4.888.681) 482

2/42 0:10 +0.35 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 Qa5 6.Bg6+ Rxg6
7.Rxg6 (4.888.681) 482

3/52 1:23 +0.94 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qc5 5.Rxc5 Bxc5 6.Bg6+ Kf8
7.Bh5 Be7 (41.322.691) 494

4/52 2:07 +1.24 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qc2+
4.Kf1 Qc3 5.Bg6+ Ke7 6.Qxg8 Rxg6
7.Rxc7+ Qxc7 8.Rxg6 (62.660.413) 492

5/54 3:36 +0.94 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qc5 5.Rxc5 Bxc5 6.Bg6+ Kf8
7.Bh5 Be7 (106.677.056) 492

5/54 5:57 +1.44 1.a6 bxa6 2.Nd3 Qc3 3.Rb2 Ba7 4.Rb7 Qd2+
5.Kf1 Bb6 6.Rb8 g2+ 7.Rxg2 Qxg2+
8.Kxg2 Rxb8 9.Nb4 Bd4 (178.702.339) 500

Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
Top
User avatar
Eelco de Groot
Posts: 4676
Joined: Sun Mar 12, 2006 2:40 am
Full name:   Eelco de Groot

Re: Vescovi-Shaked, Mermaid Beach Club 1997

Post by Eelco de Groot »

In spite of misgivings I tried to reach a ply deeper but I don't think we will make it, a pity because in the final 5 ply iterations, which are just in after 400 minutes the eval actually sank. It is all very strange, but I don't think we will be able to get more out of this version soon...

[d]6r1/1pp2knQ/3p1r2/P2Pq3/2P1BpR1/4bPp1/R5K1/4N3 w - -

Engine: Blueberry Beta 4 DM70 NoSE Build 448 (128 MB)
by F. Letouzey, T. Gaksch, E. de Groot

1/16 0:00 -5.05 1.Rxg7+ Rxg7 2.Nd3 (1.328)

1/16 0:00 -2.65 1.Nc2 (1.330)

1/16 0:00 -2.27 1.Nd3 (1.332)

1/16 0:00 -1.23 1.Kf1 (2.010)

2/37 0:00 -0.83 1.Kf1 Kf8 2.Nd3 (199.867)

2/37 0:00 -0.53 1.Bg6+ Kf8 2.Nd3 Qd4 3.Rb2 b6 4.Kh3 Qxc4
5.axb6 Bxb6 (350.083)

2/38 0:01 -0.63 1.Bg6+ Kf8 2.Nd3 Qd4 3.Rb2 Qxc4
4.Rxb7 Ne8 5.Kh1 Qxd5 (584.107) 450

2/38 0:02 -0.49 1.Nd3 Qc3 2.Bg6+ Kf8 3.Rb2 Qxc4
4.Rxb7 Ne8 (1.343.068) 440

2/41 0:05 0.00 1.Nd3 Qd4 2.Rb2 b6 3.Bg6+ Kf8 4.axb6 cxb6
5.Ra2 Ne8 6.Qh6+ Ke7 7.Qh7+ Kf8 (2.421.140) 482

2/42 0:10 +0.35 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 Qa5 6.Bg6+ Rxg6
7.Rxg6 (4.888.681) 482

2/42 0:10 +0.35 1.Nd3 Qc3 2.Rb2 Qxa5 3.Rxb7 Qa2+
4.Kf1 Qa1+ 5.Ne1 Qa5 6.Bg6+ Rxg6
7.Rxg6 (4.888.681) 482

3/52 1:23 +0.94 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qc5 5.Rxc5 Bxc5 6.Bg6+ Kf8
7.Bh5 Be7 (41.322.691) 494

4/52 2:07 +1.24 1.Nd3 Qc3 2.Rb2 Qxc4 3.Rxb7 Qc2+
4.Kf1 Qc3 5.Bg6+ Ke7 6.Qxg8 Rxg6
7.Rxc7+ Qxc7 8.Rxg6 (62.660.413) 492

5/54 3:36 +0.94 1.Nd3 Qc3 2.Rb2 Qxc4 3.Ne5+ dxe5
4.Rc2 Qc5 5.Rxc5 Bxc5 6.Bg6+ Kf8
7.Bh5 Be7 (106.677.056) 492

5/54 5:57 +1.44 1.a6 bxa6 2.Nd3 Qc3 3.Rb2 Ba7 4.Rb7 Qd2+
5.Kf1 Bb6 6.Rb8 g2+ 7.Rxg2 Qxg2+
8.Kxg2 Rxb8 9.Nb4 Bd4 (178.702.339) 500

5/61 132:20 +1.79 1.a6 bxa6 2.Nd3 Qc3 3.Rb2 Ba7 4.Rb7 Qd2+
5.Kf1 Bb6 6.Rb8 g2+ 7.Rxg2 Qxg2+
8.Kxg2 Rxb8 9.Nb4 Bd4 10.Nxa6 Rb2+
11.Bc2 (4.368.079.919) 550

5/61 400:04 +1.29 1.a6 bxa6 2.Nd3 Qc3 3.Rb2 Ba7 4.Rb7 Bb6
5.Rb8 Qc2+ 6.Kf1 g2+ 7.Rxg2 Qxg2+
8.Kxg2 Rxb8 9.Qh4 Be3 10.Qg4 Kf8 (13.219.143.095) 550

5/61 400:04 +1.29 1.a6 bxa6 2.Nd3 Qc3 3.Rb2 Ba7 4.Rb7 Bb6
5.Rb8 Qc2+ 6.Kf1 g2+ 7.Rxg2 Qxg2+
8.Kxg2 Rxb8 9.Qh4 Be3 10.Qg4 Kf8 (13.219.143.095) 550

Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
Top
User avatar
Eelco de Groot
Posts: 4676
Joined: Sun Mar 12, 2006 2:40 am
Full name:   Eelco de Groot

Re: Vescovi-Shaked, Mermaid Beach Club 1997

Post by Eelco de Groot »

Okay one more post about this one position, as it is a bit slow, Blueberry and forum posting I mean. Six plies was finally reached a minute ago, I just happened to see it come in, strange coincidence that I was just watching. The eval has gone up a bit, but only to what it was in the first iteration at ply 5. I think White can do better than this, there are better moves but at least I have some sort of baseline how long it takes to finish six plies. That's why it has a purpose to run it for so long. But actually I have no real idea why the extreme difference between completing the 5 ply 1.a6 iteration and the six ply one. Thanks for reading!


6/65 1292:09 +1.44 1.a6 bxa6 2.Nd3 Qc3 3.Rb2 Ba7 4.Rb7 Bb6
5.Rb8 Qd2+ 6.Kf1 g2+ 7.Rxg2 Qxg2+
8.Kxg2 Rxb8 9.Nb4 a5 10.Nc6 Ra8
11.Bc2 (44.449.359.753) 573
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Vescovi-Shaked, Mermaid Beach Club 1997

Post by bob »

When you use the term "singular extensions" can you explain what you mean, since it obviously is not what the Deep Blue guys described in their paper on this topic???
Top
User avatar
Eelco de Groot
Posts: 4676
Joined: Sun Mar 12, 2006 2:40 am
Full name:   Eelco de Groot

Re: Vescovi-Shaked, Mermaid Beach Club 1997

Post by Eelco de Groot »

bob wrote:When you use the term "singular extensions" can you explain what you mean, since it obviously is not what the Deep Blue guys described in their paper on this topic???
Hello Robert,

I would not know if what I call singular extensions is very different from what Hsu described, I have never read any of the technical papers on singular extensions, nor the one by Hsu that started it all. I think what I tried to make is based on a similar idea though. But I called it a "hack" before when I posted some code and that code is still essentially unchanged.

The code is turned of in the PV searches right now for which singular extensions are originally meant. That is just one difference, but I don't think what is left is really different from the singular extensions like in Deep Thought (I think it was Deep Thought?). I might switch it on again, it is not the most important factor causing the slow downs. And what I should say first this is more a learning tool for me to see what it does, I have no real immediate goals that the code should bring elo.

But what I had in mind for it is maybe more valid than the code itself. The thought was mainly that when search trees are growing larger, the usefullness, for advanced nodes especially, from iterative deepening is limited. There is a big timegap between a node being visited on successive iterations and especially in a game it may pay off taking into account that it may not be possible to visit this node again before the time is up. When the normal search for this node is done, you have collected a lot of information but you only pass down one value information and store one move for every subsearch call. Also, if the best move in the node really stands out and the eval is not accurate, the second best move can't really take over its role. So it becomes more important to test best_move for a fail low. Based on this I extend best_move after all moves in the node have been searched to nominal depth but before returning the value of best_move. I wanted to limit the extra searching for accurate nformation on what is the second best move, for that would be doing multi-PV, which is expensive, though maybe not so expensive as doing it for the root node. So I simply tried to make some stack structure, I'm sure it could be better structured, and whenever a new best move is found in the first search it pushes the old move to second place and I declare this the "second_best_ move" It's more like a second option to try when best_move fails low after extending it, but it will work. I also have third_best_move but doing something with that (in case second_best does not go higher than best_move) is probably not worth it. When I tried that it seemed only to slow things down. That is basically it, a weak point of the code as it is now is maybe the recursiveness, now a front node can be visited numerous times because when the values get passed down to the root every PV node can decide to do a singular extension after the first pass. You have to limit that somehow and avoid starting singular extensions to deep. On the other hand doing extensions too often near the root is also not good, after a while your root move sequences are so good that new singular extensions are just completely wasted because you already have an accurate picture of what is best there. But that is not in the code yet, I only limit starting searches to a maximum distance from the depth you would normally reach on this iteration (condition: height <= SearchCurrent[ThreadId]->act_iteration + 8)


There are several other bells and whistles added later that are probably confusing, such as also extending if the value is very close to zero (condition:|| (best_value >= -5 && best_value <= 5 && nextbest_value <= -50)) Singular extension conditions, one move much better than the rest, does not apply (near zero all values can be compressed but likely not all are draws) but I still would like to see if this move really leads to a draw. I could have made that a separate form of extension, I have not done much testing here.

Also an extension that kicks in as a result of null-move (condition: || NonPVThreatExtension) that is not really of the same form as the rest of the extension, that could have been put into a separate codeblock maybe.

(condition: depth <= 30) is there because otherwise I would give negative deltas, the distance that the best move is better than the second_best_move, also a chance to extend by (condition:best_value - nextbest_value) >= (300 - 10 * depth)), and that is not what I want. The delta calculation does not apply in case best_move is very close to zero and extended for that reason, that is a weak point in the code.

Here is a sample of the latest code, sorry for its very basic code structures, lack of comments etcetera. I would rather post something that I knew was working, but this is Blueberry as it is now... :P

UseSingularExtensions = false everywhere (at the moment) but singular_reply is a variable given to every nullwindow search and is mostly true for all these searches and overrides UseSingularExtensions in that case. Because I think most of these should produce an answer > beta on the first pass, the effect of switching this on in nullwindowsearches is limited (condition: best_value < beta) but singular extensions tried for nullwindow searches did not seem too bad overall. I had expected the searches to explode all over the place so I was very surprised...

Also I'm using (at the moment) some sort of scouting nullwindow searches in PV nodes before calling the actual PV node search, these go much deeper than the actual PV node search so that gives maybe enough singular extensions effects already (because they are nullwindow searches, with singular_reply = true) that switching singular extensions off in the last PV node search is now a bit better. These scouting searches may have to go again though, or be decreased, because they are pretty costly.

Code: Select all

   // [EdG: single reply extensions hack]
    
   if ((UseSingularExtensions || singular_reply) && best_move != MoveNone && nextbest_value != ValueNone /* && thirdbest_value != ValueNone */ 
	   && (node_type == NodePV || singular_reply || NonPVThreatExtension) && best_value < beta
	   && depth_best_move < depth && ((best_value - nextbest_value) >= (300 - 10 * depth) 
	   || (best_value >= -5 && best_value <= 5 && nextbest_value <= -50)/*||
	   ((best_value - thirdbest_value) >= (500 - 5 * depth))*/) && depth <= 30 
	   && height <= SearchCurrent[ThreadId]->act_iteration + 8){// [EdG:[]'only move' hack]
	  move_do(board,best_move,undo);
	  value = -full_search(board,-beta,-alpha,depth_best_move + 1,height+1,new_pv,NodePV,true,false,ThreadId);
	  Singular_Extended = true;
	  if (ABS(best_value - value) >= (50 + 3 * height)) {
		 value = -full_search(board,-beta,-alpha,depth_best_move + 1,height+1,new_pv,NodePV,true,false,ThreadId);
         Doubly_Extended = true;
	  }
	  //value = -full_search(board,-beta,-alpha,depth_best_move + 2,height+1,new_pv,NodePV,cap_extended,ThreadId);
	  //value = -full_search(board,-beta,-alpha,depth_best_move + 3,height+1,new_pv,NodePV,cap_extended,ThreadId);
	  move_undo(board,best_move,undo);
	  
	  best_value = value;
	  pv_cat(pv,new_pv,best_move);

	  ASSERT(value_is_ok(best_value));

      if (value > alpha) {
         alpha = value;
      }
	  if (value < (nextbest_value + 150 - 5 * depth)) {
		 move_do(board,nextbest_move,undo);
		 nextbest_value = -full_search(board,-(value + 1),-(value - 1),depth_best_move,height+1,new_pv,NodePV,true,false,ThreadId);
         nextbest_value = -full_search(board,-beta,-alpha,depth_best_move + 1,height+1,new_pv,NodePV,true,false,ThreadId);
		 if (Doubly_Extended)
			nextbest_value = -full_search(board,-beta,-alpha,depth_best_move + 2,height+1,new_pv,NodePV,true,false,ThreadId);
         move_undo(board,nextbest_move,undo);
		 if (value < nextbest_value) {
           best_value = nextbest_value;
		   best_move = nextbest_move;
		   pv_cat(pv,new_pv,nextbest_move);
		    		 
		   ASSERT(value_is_ok(best_value));

           if (best_value > alpha) {
              alpha = best_value;
           }
		 } 
	  }
Best regards,
Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Vescovi-Shaked, Mermaid Beach Club 1997

Post by bob »

The reason I asked is that I implemented Hsu's original SE algorithm in the last couple of years of Cray Blitz and it was a +huge+ change. Searching fail high and PV nodes with an offset window to see if just one move would fail high and the rest would fail low, then extending the fail high move as "singular". And the devil was in the details. A sticky transposition table to flag moves that were previously extended so that at least for the next iteration, they would be extended even if the singular test failed.

It cost us over a ply of search. I don't remember exact numbers as this was 1993-1994 and that code is long gone (lost in 1995 due to a disk crash).

I do have a cheapo-version on the back burner to test again at some point in time, and that code is in Crafty's C code format so it is waiting its chance for testing again.
Top

Return to “Computer Chess Club: General Topics”