STS (v3.0) - Knight Outposts/Centralization/Repositioning

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

Moderators: hgm, Rebel, chrisw

swami
Posts: 6640
Joined: Thu Mar 09, 2006 4:21 am

Re: STS (v3.0) - complete data (3 tests)

Post by swami »

bob wrote:
Dann Corbit wrote:
bob wrote:Since I have seen some odd results Here are the three sets of positions run on my 8-core box. Order is undermine, then file-diag, then knights. 30 secs/position, stop if correct move is chosen on 6 consecutive iterations:

Code: Select all

total positions searched..........         100
number right......................          85
number wrong......................          15
percentage right..................          85
percentage wrong..................          15
total nodes searched.............. 16161816467
average search depth..............        13.1
nodes per second..................    16536365
total time........................       16:17

total positions searched..........         100
number right......................          89
number wrong......................          11
percentage right..................          89
percentage wrong..................          11
total nodes searched.............. 17665398896
average search depth..............        13.2
nodes per second..................    17172546
total time........................       17:08

total positions searched..........         100
number right......................          96
number wrong......................           4
percentage right..................          96
percentage wrong..................           4
total nodes searched..............  3482397961
average search depth..............         9.1
nodes per second..................    16628774
total time........................        3:29
based on the search time needed, the last batch is by far the easiest...
I've seen other fairly strong programs have equal problems with this set that they have had with the others. I think crafty is just really good with knight moves for whatever reason.
I am not sure why. It's knight scoring is about as simple as it can get...
Well, That's some modesty, Bob. I have seen many top engines doing somewhat average in this test suite particularly. Clearly, Crafty has better knight understanding than any others though. But I will once again verify the results to make sure that comparison is quite correct.

You reported Crafty got 85's in previous tests but 95 in this one. That alone is indication. For me, Glaurung, Bright and Fruit get over 80's in previous tests (undermining/Open Files and Diagonals) whereas they only get 70-72 in Knight centralization. That's hefty difference when you contrast this against crafty.

So, Maybe it's not to do with Knight scoring in your code, maybe other factors do play some role here, like any pieces, let alone a knight, taking complete control of the center, choosing correct squares for outposts, Reposition pieces to lead the better path etc...
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: STS (v3.0) - complete data (3 tests)

Post by bob »

swami wrote:
bob wrote:
Dann Corbit wrote:
bob wrote:Since I have seen some odd results Here are the three sets of positions run on my 8-core box. Order is undermine, then file-diag, then knights. 30 secs/position, stop if correct move is chosen on 6 consecutive iterations:

Code: Select all

total positions searched..........         100
number right......................          85
number wrong......................          15
percentage right..................          85
percentage wrong..................          15
total nodes searched.............. 16161816467
average search depth..............        13.1
nodes per second..................    16536365
total time........................       16:17

total positions searched..........         100
number right......................          89
number wrong......................          11
percentage right..................          89
percentage wrong..................          11
total nodes searched.............. 17665398896
average search depth..............        13.2
nodes per second..................    17172546
total time........................       17:08

total positions searched..........         100
number right......................          96
number wrong......................           4
percentage right..................          96
percentage wrong..................           4
total nodes searched..............  3482397961
average search depth..............         9.1
nodes per second..................    16628774
total time........................        3:29
based on the search time needed, the last batch is by far the easiest...
I've seen other fairly strong programs have equal problems with this set that they have had with the others. I think crafty is just really good with knight moves for whatever reason.
I am not sure why. It's knight scoring is about as simple as it can get...
Well, That's some modesty, Bob. I have seen many top engines doing somewhat average in this test suite particularly. Clearly, Crafty has better knight understanding than any others though. But I will once again verify the results to make sure that comparison is quite correct.

You reported Crafty got 85's in previous tests but 95 in this one. That alone is indication. For me, Glaurung, Bright and Fruit get over 80's in previous tests (undermining/Open Files and Diagonals) whereas they only get 70-72 in Knight centralization. That's hefty difference when you contrast this against crafty.

So, Maybe it's not to do with Knight scoring in your code, maybe other factors do play some role here, like any pieces, let alone a knight, taking complete control of the center, choosing correct squares for outposts, Reposition pieces to lead the better path etc...
I did not look at each position so can't comment very well yet, but Crafty's knight evaluation is very simple, really with just three ideas included.

1. piece/square table to centralize knights.

2. outpost knights, with a bonus for no enemy pawn that can attack the knight and another bonus if no enemy knight or bishop can attack the knight.

3. Mobility with mobility to central squares being worth more than mobility to edge squares.

Really simple, hardly shows up on profile runs. Which leads me to believe that this test may be more about simple plans to get the knight to good squares. Could mean our knight scoring is over-valued, possibly.
Dann Corbit
Posts: 12542
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: STS (v3.0) - complete data (3 tests)

Post by Dann Corbit »

bob wrote:
swami wrote:
bob wrote:
Dann Corbit wrote:
bob wrote:Since I have seen some odd results Here are the three sets of positions run on my 8-core box. Order is undermine, then file-diag, then knights. 30 secs/position, stop if correct move is chosen on 6 consecutive iterations:

Code: Select all

total positions searched..........         100
number right......................          85
number wrong......................          15
percentage right..................          85
percentage wrong..................          15
total nodes searched.............. 16161816467
average search depth..............        13.1
nodes per second..................    16536365
total time........................       16:17

total positions searched..........         100
number right......................          89
number wrong......................          11
percentage right..................          89
percentage wrong..................          11
total nodes searched.............. 17665398896
average search depth..............        13.2
nodes per second..................    17172546
total time........................       17:08

total positions searched..........         100
number right......................          96
number wrong......................           4
percentage right..................          96
percentage wrong..................           4
total nodes searched..............  3482397961
average search depth..............         9.1
nodes per second..................    16628774
total time........................        3:29
based on the search time needed, the last batch is by far the easiest...
I've seen other fairly strong programs have equal problems with this set that they have had with the others. I think crafty is just really good with knight moves for whatever reason.
I am not sure why. It's knight scoring is about as simple as it can get...
Well, That's some modesty, Bob. I have seen many top engines doing somewhat average in this test suite particularly. Clearly, Crafty has better knight understanding than any others though. But I will once again verify the results to make sure that comparison is quite correct.

You reported Crafty got 85's in previous tests but 95 in this one. That alone is indication. For me, Glaurung, Bright and Fruit get over 80's in previous tests (undermining/Open Files and Diagonals) whereas they only get 70-72 in Knight centralization. That's hefty difference when you contrast this against crafty.

So, Maybe it's not to do with Knight scoring in your code, maybe other factors do play some role here, like any pieces, let alone a knight, taking complete control of the center, choosing correct squares for outposts, Reposition pieces to lead the better path etc...
I did not look at each position so can't comment very well yet, but Crafty's knight evaluation is very simple, really with just three ideas included.

1. piece/square table to centralize knights.

2. outpost knights, with a bonus for no enemy pawn that can attack the knight and another bonus if no enemy knight or bishop can attack the knight.

3. Mobility with mobility to central squares being worth more than mobility to edge squares.

Really simple, hardly shows up on profile runs. Which leads me to believe that this test may be more about simple plans to get the knight to good squares. Could mean our knight scoring is over-valued, possibly.
Very long searches by top level engines on good hardware show that these positions have one best answer, that crafty selects very quickly almost all the time.

To me, that indicates "less is more" when it comes to knight evaluation. The simple approach chosen by crafty is the right way to do it. And if it happens with microscopic computation charge, so much the better.
User avatar
michiguel
Posts: 6401
Joined: Thu Mar 09, 2006 8:30 pm
Location: Chicago, Illinois, USA

Re: STS (v3.0) - Knight Outposts/Centralization/Repositionin

Post by michiguel »

swami wrote:Chapter 3 Of the Strategic Test Suite: Knight Outposts, Centralization and Repositioning is now available for download.

* Consists of carefully selected 100 questionairres on Knight OutPosts/Centralization/Repositioning

* All of the questions in this test suite are selected by me and thoroughly verified by Dann Corbitt. Each question has been analysed by top engines for hours.

* All the answers carry similar traits:
  • (1) A Knight move to take control of the center or posit itself in the center. (Centralization)
    (2) A Knight move to step back and reposition itself to lead the different (or better) path. (Repositioning)
    (3) A Knight move to take control of the opponent's weak squares (Outposts)
I initially selected about 190 problems and sent them to Dann, of which 100 has passed criteria. Dann made the final selection and done all that analysis with the help of the engines.

Recommended time: Anywhere between 10 seconds - 2 minutes for each test.

Download it here: STS 3.0
http://computerchessblogger.googlepages.com/sts

Feel free to report the results from your engine/ favourite engine, suggestions are welcome.

Special Thanks to Pedro Castro, Allard Siemelink, Zach Wegner for the testing and correcting mistakes throughout the process. And Thanks to those who reported bugs and tested out the V 1.0 of the test suite called "Undermining", and v2.0 called "Open Files and Diagonals".

And Extra Special Thanks to Ulysses for creating the beautiful logo!

Test Suite Released time: 3rd of June, 2009
Swaminathan and Dann Corbit.
Gaviota 0.65
10 seconds, AMD 2.4 Ghz, 16 Mb hash.
Right: 62
Wrong: 38

Miguel
swami
Posts: 6640
Joined: Thu Mar 09, 2006 4:21 am

Re: STS (v3.0) - Knight Outposts/Centralization/Repositionin

Post by swami »

michiguel wrote:
swami wrote:Chapter 3 Of the Strategic Test Suite: Knight Outposts, Centralization and Repositioning is now available for download.

* Consists of carefully selected 100 questionairres on Knight OutPosts/Centralization/Repositioning

* All of the questions in this test suite are selected by me and thoroughly verified by Dann Corbitt. Each question has been analysed by top engines for hours.

* All the answers carry similar traits:
  • (1) A Knight move to take control of the center or posit itself in the center. (Centralization)
    (2) A Knight move to step back and reposition itself to lead the different (or better) path. (Repositioning)
    (3) A Knight move to take control of the opponent's weak squares (Outposts)
I initially selected about 190 problems and sent them to Dann, of which 100 has passed criteria. Dann made the final selection and done all that analysis with the help of the engines.

Recommended time: Anywhere between 10 seconds - 2 minutes for each test.

Download it here: STS 3.0
http://computerchessblogger.googlepages.com/sts

Feel free to report the results from your engine/ favourite engine, suggestions are welcome.

Special Thanks to Pedro Castro, Allard Siemelink, Zach Wegner for the testing and correcting mistakes throughout the process. And Thanks to those who reported bugs and tested out the V 1.0 of the test suite called "Undermining", and v2.0 called "Open Files and Diagonals".

And Extra Special Thanks to Ulysses for creating the beautiful logo!

Test Suite Released time: 3rd of June, 2009
Swaminathan and Dann Corbit.
Gaviota 0.65
10 seconds, AMD 2.4 Ghz, 16 Mb hash.
Right: 62
Wrong: 38

Miguel
Hi Miguel, This is very good results actually considering the engine only used 16mb hash that too on AMD 2.4 Ghz. Glaurung scored 72, Spike 73 and Pro Deo 76 on core 2 Quad 2.6 Ghz.

Pharaon and Pro Deo have very good understanding of this and they score more than top freewares - Glaurung, Fruit, Bright and Spike, despite being 100-200 elo lower.
swami
Posts: 6640
Joined: Thu Mar 09, 2006 4:21 am

Re: STS (v3.0) - Knight Outposts/Centralization/Repositionin

Post by swami »

MattieShoes wrote:Moneypenny 10 seconds:

Code: Select all

Number of tests:                       100
Max score:                             1000
Engines score:                         602
Number with full score:                45
Found in: 5 sec = 15, 10 sec = 30,
Time used for tests (wrong answer=10s): 811s
Moneypenny 2 minutes:

Code: Select all

Number of tests:                       100
Max score:                             1000
Engines score:                         641
Number with full score:                54
Found in: 1 min = 15, 2 min = 39,
Time used for tests (wrong answer=120s): 9685s
Gerbil scored 39/100 and Lodocase 43/100 on Core2Quad. If anything, Moneypenny is surely at 1900 already.

I'd be curious how the engine would do in actual games if some tweaking is done mainly to optimise its score in all the 3 test suites. Would it improve the general playing strength? That would be interesting thing to experiment. On the other hand, Is tweaking even possible? changing some score values for pieces or priority for certain concepts?

Regards.
swami
Posts: 6640
Joined: Thu Mar 09, 2006 4:21 am

Re: STS (v3.0) - complete data (3 tests)

Post by swami »

bob wrote:1. piece/square table to centralize knights.

2. outpost knights, with a bonus for no enemy pawn that can attack the knight and another bonus if no enemy knight or bishop can attack the knight.

3. Mobility with mobility to central squares being worth more than mobility to edge squares.
Interesting. Makes me wonder if all programmers of >2600 engines have good understanding of advanced rules in chess strategies that's required of a IM or other strong chess players? Did you study a lot of strategical books in chess, Bob, to be able to determine some sort of importances for certain concepts? If so, that's impressive.

Maybe you heard of these rules over years of experience discussing chess with IM's, and that they gave you some sort of rules on Do's/Don'ts in strategies, and you just implemented them promtly as you go along?

perhaps its all too simple and common knowledge for all programmers, and that I'm just not expecting much and holding on to my belief that they are all secret and difficult to obtain knowledge?

Am I right in thinking that there's too much principles and values to implement on a strong playing chess program, so that it wouldn't make any positional errors?

Do you have the complete details of whatever inputs related to values, bonuses, principles and strategies, you've so far given to Crafty? I'd be interested in such a documentation.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: STS (v3.0) - complete data (3 tests)

Post by bob »

swami wrote:
bob wrote:1. piece/square table to centralize knights.

2. outpost knights, with a bonus for no enemy pawn that can attack the knight and another bonus if no enemy knight or bishop can attack the knight.

3. Mobility with mobility to central squares being worth more than mobility to edge squares.
Interesting. Makes me wonder if all programmers of >2600 engines have good understanding of advanced rules in chess strategies that's required of a IM or other strong chess players? Did you study a lot of strategical books in chess, Bob, to be able to determine some sort of importances for certain concepts? If so, that's impressive.

Maybe you heard of these rules over years of experience discussing chess with IM's, and that they gave you some sort of rules on Do's/Don'ts in strategies, and you just implemented them promtly as you go along?

perhaps its all too simple and common knowledge for all programmers, and that I'm just not expecting much and holding on to my belief that they are all secret and difficult to obtain knowledge?

Am I right in thinking that there's too much principles and values to implement on a strong playing chess program, so that it wouldn't make any positional errors?

Do you have the complete details of whatever inputs related to values, bonuses, principles and strategies, you've so far given to Crafty? I'd be interested in such a documentation.
For your last question first, no, other than what is in the comments. I have tried to include all the "normal" ideas into the evaluation. pawn structure, piece placement, etc. But there is a long way to go, since the knowledge/speed tradeoff is ever-present.

I think our mobility is done "right", although it is not as good as what we had in the last versions of Cray Blitz that were lost. I do not believe that mobility, just for the sake of mobility is very good. we currently weight squares based on centrality (for knights). In Cray Blitz we weighted squares by computing the weights as we did the eval, so that we had an idea of which squares were weak, which pawns were weak, etc, and mobility factored in those weights that could be different for every square (cute vector merge instruction let us get away with this for zero cost). In any case, knights are not magic in what we do, attract them toward the center, evaluate outposts as I mentioned previously, and then factor in mobility. The knight's position is factored into king safety, but not in the code that evaluates knights, this is done in the EvaluateKing() code.

As far as "where did the ideas come from?" I've read most books that others read over the years, and probably some that have been missed. "Point count chess" appeared to be a perfect one for computer chess, but although the ideas were good, it was unusable as an evaluation model. "My System" was my favorite for improving my own play and many of his ideas therefore influenced Crafty's evaluation. Other ideas came from prodding by Roman Dzhindi (candidate pawn evaluation, as one example).
User avatar
Eelco de Groot
Posts: 4567
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: STS (v3.0) - Knight Outposts/Centralization/Repositionin

Post by Eelco de Groot »

Hello Swami and Dann,

Thanks for the testsuite! I was just messing with Bishop and Knight mobility, so this test comes at the right time :shock:

Results with Ancalagon build 134:

Code: Select all

Engine: Ancalagon 1.3 WS180 Build 134 (256 MB)
by Romstad, Costalba, Kiiski, de Groot
Right until now: 70 of 100  ;  6:49m
10 seconds per position

     1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20
  --------------------------------------------------------------------------------
  |  2   0   0   2   8   -   1   0   -   2   4   0   -   2   0   -   0   -   5   0
  |  -   -   0   1   3   -   0   0   0   1   1   0   0   -   1   0   0   8   0   0
  |  -   0   0   0   -   0   2   0   3   0   1   1   -   0   6   -   3   -   0   5
  |  0   -   -   0   -   1   3   -   1   0   1   3   -   7   -   -   -   0   0   1
  |  0   3   -   -   0   0   0   0   0   0   0   -   0   -   -   1   -   -   0   -

   1 sec ->  40/100
   2 sec ->  52/100
   3 sec ->  57/100
   4 sec ->  63/100
   5 sec ->  64/100
   6 sec ->  66/100
   7 sec ->  67/100
   8 sec ->  68/100
   9 sec ->  70/100
  10 sec ->  70/100
  n/s: 681.287  
  TotTime: 16:57m    SolTime: 6:49m
I have some doubts about the last position, position No. 100? More or less at random I let this one run a little longer, because Ancalagon switched at the last moment from 1. Nd4 to 1. Nhf4, which you only have as third choice. First I tried to improve the analysis as the switch seemed more a slight instability but then this move was chosen for six consecutive plies, before 1.Nd4 takes over again with a minimal difference. Maybe 1. Nhf4 is a dangerous move and only Rybka 3 sees it and it could have something to do with King Safety if the Knight does not block h4 anymore, but then I would expect other programs to see that on deeper plies as well...

[D]rqr3k1/1p2bppp/3pn3/p3p1Pn/P3P3/1PNBBP2/1P1Q3P/2KR3R b - - bm Nd4; c0 "Nd4=10, Nef4=6, Nhf4=5"; id "STS: Knight Outposts/Repositioning/Centralization.100";


rqr3k1/1p2bppp/3pn3/p3p1Pn/P3P3/1PNBBP2/1P1Q3P/2KR3R b - -

Engine: Ancalagon 1.3 WS180 Build 134 (Athlon 2009 MHz, 256 MB)
by Romstad, Costalba, Kiiski, de Groot

2.00 0:00 +1.52 1...Nd4 2.Kb1 Nxb3 (3.351) 14

3.00 0:00 +1.52 1...Nd4 2.Kb1 Nxb3 (32.652) 116

4.00 0:00 +1.25 1...Nd4 2.Kb1 (49.591) 158

5.00 0:00 +0.82 1...Nd4 2.Bc2 Nxc2 3.Qxc2 b6 4.Rhg1 Qb7 (139.008) 296

6.00 0:00 +0.82 1...Nd4 2.Bc2 Nxc2 3.Qxc2 b6 4.Rhg1 Qb7 (290.049) 403

7.00 0:01 +0.39 1...Nd4 2.Bc2 (594.921) 494

8.01 0:02 +0.39 1...Nd4 2.Bc2 Nxc2 3.Qxc2 b6 4.h4 Ra7
5.Kb1 Rac7 (1.378.947) 569

9.01 0:04 +0.29 1...Nd4 2.Bc2 Nxc2 3.Kxc2 b5 4.Kb1 bxa4
5.bxa4 Ra6 6.h4 (3.000.435) 613


9.02 0:05 +0.29 1...Nhf4 (3.175.655) 621

10.01 0:08 +0.17 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Qa8 7.Rxc6 bxc6 (5.742.130) 676

11.01 0:17 +0.15 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Qa8 7.Rc3 (12.334.464) 691

12.01 0:38 0.00 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Qa8 7.Rc3 b6 (27.775.179) 723


12.02 0:42 0.00 1...Nd4 (30.811.698) 724

13.01 1:30 -0.09 1...Nd4 2.Bc2 Bd8 3.Bxd4 exd4 4.Nb5 d5
5.Kb1 dxe4 6.Bxe4 Qe5 7.Qxd4 Qxd4
8.Nxd4 Bxg5 9.Bxb7 (65.024.750) 717

14.01 3:35 -0.17 1...Nd4 2.Bc2 Bd8 3.Bxd4 exd4 4.Nb5 d3
5.Qxd3 Bxg5+ 6.Kb1 Nf4 7.Qxd6 Bf6
8.Rhe1 Rd8 9.Qxb8 Raxb8 10.Rxd8+ Rxd8
11.e5 (154.085.660) 715


14.02 3:53 -0.17 1...Nhf4 (166.871.375) 715

15.01 7:49 -0.11 1...Nhf4 2.h4 Nc5 3.Bc2 Nfd3+ 4.Kb1 Nb4
5.Nd5 Nxd5 6.Qxd5 b5 7.g6 hxg6 8.h5 gxh5
9.Rxh5 bxa4 10.bxa4 (326.864.061) 696

16.01 14:18 -0.25 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Bd8
5.Nd5 Rac6 6.Rc1 Rxc1+ 7.Rxc1 Rc6
8.Bf2 Qc8 9.Rc3 f6 10.gxf6 Bxf6
11.Rxc6 Qxc6 (574.508.523) 669

17.01 33:24 -0.31 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Bd8
5.Nd5 Rac6 6.Rc1 Rxc1+ 7.Rxc1 Rxc1+
8.Kxc1 Qc8+ 9.Kd2 Qc6 10.Bb6 Qe8
11.Bf2 Qc6 12.Qc4 (1.219.401.813) 608

18.01 79:49 -0.33 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Rxc1+ 7.Rxc1 Rxc1+
8.Kxc1 Qc8+ 9.Qc3 Qd7 10.Bf2 b5
11.axb5 Qxb5 12.Qc4 Qd7 13.Kc2 (2.616.443.704) 546

19.01 209:55 -0.49 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Rc6 4.Kb1 Qc8
5.Nd5 Bd8 6.Rc1 Qd7 7.Rc3 Rac8
8.Rhc1 Kh8 9.Qb5 Nd4 10.Bxd4 exd4
11.Rc4 Kg8 (6.631.363.799) 526


19.05 264:58 -0.48 1...Nd4 (8.545.491.341) 537


Rybka 2.2n2 also makes little distinction between these two moves:


rqr3k1/1p2bppp/3pn3/p3p1Pn/P3P3/1PNBBP2/1P1Q3P/2KR3R b - -

Engine: Rybka 2.2n2 mp 32-bit PVtips5menbases (64 MB)
by Vasik Rajlich

16 3:05 -0.10 1...Nd4 2.Bc2 Rc6 3.Kb1 Qd8 4.Bxd4 exd4
5.Qxd4 Bxg5 6.e5 Bf4 7.exd6 Rxd6 8.Qe4 g6
9.Nd5 Bg5 10.Rhg1 (7.350.481) 40

16 3:40 -0.18 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Qb5 Qa8 7.b4 Nc7 8.Nxc7 Bxc7
9.Rc1 axb4 (8.861.845) 41
_____________________________________________________________

17 6:39 -0.16 1...Nd4 2.Bc2 Rc6 3.Kb1 Nxc2 4.Qxc2 Qf8
5.h4 Bd8 6.Qd2 f5 7.Nb5 f4
8.Bf2 Raa6 (16.584.151) 42

17 7:57 -0.19 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Qb5 Qa8 7.Bb6 Kh8
8.Rc1 Qb8 9.Rc4 Bxb6 (19.837.347) 42
_____________________________________________________________

18 11:37 -0.14 1...Nd4 2.Bc2 Rc6 3.Kb1 Nxc2 4.Qxc2 Qf8
5.Qd3 f6 6.gxf6 Bxf6 7.Nd5 Bd8
8.Rhg1 Qf7 9.Rc1 (29.504.866) 43

18 14:42 -0.21 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Qe2 Kf8 6.Nd5 Bd8 7.Qb5 Qa8 8.b4 axb4 (37.295.849) 43
_____________________________________________________________

19 34:08 -0.30 1...Nd4 2.Qf2 Nxb3+ 3.Kb1 Nc5 4.Bb5 b6
5.Nd5 Qb7 6.Rhg1 g6 7.Rg2 Kh8
8.Qe1 (87.739.800) 43

19 44:02 -0.31 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Rhg1 Qa8 6.h5 Qa6 7.Qd2 Bd8
8.g6 hxg6 (113.305.500) 43
_____________________________________________________________

20 66:13 -0.25 1...Nd4 2.Qf2 Nxb3+ 3.Kb1 Nc5 4.Bb5 b6
5.Nd5 Qb7 6.Rhg1 g6 7.Rg2 Kh8 8.Qe1 (168.700.155) 43

20 75:00 -0.26 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Qd2 b6 6.h5 Qb7 7.h6 g6 8.Rhg1 Nc5
9.Ka2 Ne6 (190.667.022) 43
_____________________________________________________________

21 127:28 -0.27 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Qd2 Qa8 6.h5 Qa6 7.Rhg1 Bd8 8.h6 Bb6
9.Rh1 gxh6 (319.500.612) 42


21 107:48 -0.28 1...Nd4 2.Qf2 Nxb3+ 3.Kb1 Nc5 4.Bb5 b6
5.Nd5 Qb7 6.Rhg1 g6 7.Rg2 Bd8 8.Qh4 (269.734.443) 42



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
Dann Corbit
Posts: 12542
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: STS (v3.0) - Knight Outposts/Centralization/Repositionin

Post by Dann Corbit »

Eelco de Groot wrote:Hello Swami and Dann,

Thanks for the testsuite! I was just messing with Bishop and Knight mobility, so this test comes at the right time :shock:

Results with Ancalagon build 134:

Code: Select all

Engine: Ancalagon 1.3 WS180 Build 134 (256 MB)
by Romstad, Costalba, Kiiski, de Groot
Right until now: 70 of 100  ;  6:49m
10 seconds per position

     1   2   3   4   5   6   7   8   9  10  11  12  13  14  15  16  17  18  19  20
  --------------------------------------------------------------------------------
  |  2   0   0   2   8   -   1   0   -   2   4   0   -   2   0   -   0   -   5   0
  |  -   -   0   1   3   -   0   0   0   1   1   0   0   -   1   0   0   8   0   0
  |  -   0   0   0   -   0   2   0   3   0   1   1   -   0   6   -   3   -   0   5
  |  0   -   -   0   -   1   3   -   1   0   1   3   -   7   -   -   -   0   0   1
  |  0   3   -   -   0   0   0   0   0   0   0   -   0   -   -   1   -   -   0   -

   1 sec ->  40/100
   2 sec ->  52/100
   3 sec ->  57/100
   4 sec ->  63/100
   5 sec ->  64/100
   6 sec ->  66/100
   7 sec ->  67/100
   8 sec ->  68/100
   9 sec ->  70/100
  10 sec ->  70/100
  n/s: 681.287  
  TotTime: 16:57m    SolTime: 6:49m
I have some doubts about the last position, position No. 100? More or less at random I let this one run a little longer, because Ancalagon switched at the last moment from 1. Nd4 to 1. Nhf4, which you only have as third choice. First I tried to improve the analysis as the switch seemed more a slight instability but then this move was chosen for six consecutive plies, before 1.Nd4 takes over again with a minimal difference. Maybe 1. Nhf4 is a dangerous move and only Rybka 3 sees it and it could have something to do with King Safety if the Knight does not block h4 anymore, but then I would expect other programs to see that on deeper plies as well...

[D]rqr3k1/1p2bppp/3pn3/p3p1Pn/P3P3/1PNBBP2/1P1Q3P/2KR3R b - - bm Nd4; c0 "Nd4=10, Nef4=6, Nhf4=5"; id "STS: Knight Outposts/Repositioning/Centralization.100";


rqr3k1/1p2bppp/3pn3/p3p1Pn/P3P3/1PNBBP2/1P1Q3P/2KR3R b - -

Engine: Ancalagon 1.3 WS180 Build 134 (Athlon 2009 MHz, 256 MB)
by Romstad, Costalba, Kiiski, de Groot

2.00 0:00 +1.52 1...Nd4 2.Kb1 Nxb3 (3.351) 14

3.00 0:00 +1.52 1...Nd4 2.Kb1 Nxb3 (32.652) 116

4.00 0:00 +1.25 1...Nd4 2.Kb1 (49.591) 158

5.00 0:00 +0.82 1...Nd4 2.Bc2 Nxc2 3.Qxc2 b6 4.Rhg1 Qb7 (139.008) 296

6.00 0:00 +0.82 1...Nd4 2.Bc2 Nxc2 3.Qxc2 b6 4.Rhg1 Qb7 (290.049) 403

7.00 0:01 +0.39 1...Nd4 2.Bc2 (594.921) 494

8.01 0:02 +0.39 1...Nd4 2.Bc2 Nxc2 3.Qxc2 b6 4.h4 Ra7
5.Kb1 Rac7 (1.378.947) 569

9.01 0:04 +0.29 1...Nd4 2.Bc2 Nxc2 3.Kxc2 b5 4.Kb1 bxa4
5.bxa4 Ra6 6.h4 (3.000.435) 613


9.02 0:05 +0.29 1...Nhf4 (3.175.655) 621

10.01 0:08 +0.17 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Qa8 7.Rxc6 bxc6 (5.742.130) 676

11.01 0:17 +0.15 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Qa8 7.Rc3 (12.334.464) 691

12.01 0:38 0.00 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Qa8 7.Rc3 b6 (27.775.179) 723


12.02 0:42 0.00 1...Nd4 (30.811.698) 724

13.01 1:30 -0.09 1...Nd4 2.Bc2 Bd8 3.Bxd4 exd4 4.Nb5 d5
5.Kb1 dxe4 6.Bxe4 Qe5 7.Qxd4 Qxd4
8.Nxd4 Bxg5 9.Bxb7 (65.024.750) 717

14.01 3:35 -0.17 1...Nd4 2.Bc2 Bd8 3.Bxd4 exd4 4.Nb5 d3
5.Qxd3 Bxg5+ 6.Kb1 Nf4 7.Qxd6 Bf6
8.Rhe1 Rd8 9.Qxb8 Raxb8 10.Rxd8+ Rxd8
11.e5 (154.085.660) 715


14.02 3:53 -0.17 1...Nhf4 (166.871.375) 715

15.01 7:49 -0.11 1...Nhf4 2.h4 Nc5 3.Bc2 Nfd3+ 4.Kb1 Nb4
5.Nd5 Nxd5 6.Qxd5 b5 7.g6 hxg6 8.h5 gxh5
9.Rxh5 bxa4 10.bxa4 (326.864.061) 696

16.01 14:18 -0.25 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Bd8
5.Nd5 Rac6 6.Rc1 Rxc1+ 7.Rxc1 Rc6
8.Bf2 Qc8 9.Rc3 f6 10.gxf6 Bxf6
11.Rxc6 Qxc6 (574.508.523) 669

17.01 33:24 -0.31 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Bd8
5.Nd5 Rac6 6.Rc1 Rxc1+ 7.Rxc1 Rxc1+
8.Kxc1 Qc8+ 9.Kd2 Qc6 10.Bb6 Qe8
11.Bf2 Qc6 12.Qc4 (1.219.401.813) 608

18.01 79:49 -0.33 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Rc1 Rxc1+ 7.Rxc1 Rxc1+
8.Kxc1 Qc8+ 9.Qc3 Qd7 10.Bf2 b5
11.axb5 Qxb5 12.Qc4 Qd7 13.Kc2 (2.616.443.704) 546

19.01 209:55 -0.49 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Rc6 4.Kb1 Qc8
5.Nd5 Bd8 6.Rc1 Qd7 7.Rc3 Rac8
8.Rhc1 Kh8 9.Qb5 Nd4 10.Bxd4 exd4
11.Rc4 Kg8 (6.631.363.799) 526


19.05 264:58 -0.48 1...Nd4 (8.545.491.341) 537


Rybka 2.2n2 also makes little distinction between these two moves:


rqr3k1/1p2bppp/3pn3/p3p1Pn/P3P3/1PNBBP2/1P1Q3P/2KR3R b - -

Engine: Rybka 2.2n2 mp 32-bit PVtips5menbases (64 MB)
by Vasik Rajlich

16 3:05 -0.10 1...Nd4 2.Bc2 Rc6 3.Kb1 Qd8 4.Bxd4 exd4
5.Qxd4 Bxg5 6.e5 Bf4 7.exd6 Rxd6 8.Qe4 g6
9.Nd5 Bg5 10.Rhg1 (7.350.481) 40

16 3:40 -0.18 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Qb5 Qa8 7.b4 Nc7 8.Nxc7 Bxc7
9.Rc1 axb4 (8.861.845) 41
_____________________________________________________________

17 6:39 -0.16 1...Nd4 2.Bc2 Rc6 3.Kb1 Nxc2 4.Qxc2 Qf8
5.h4 Bd8 6.Qd2 f5 7.Nb5 f4
8.Bf2 Raa6 (16.584.151) 42

17 7:57 -0.19 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Nd5 Bd8 6.Qb5 Qa8 7.Bb6 Kh8
8.Rc1 Qb8 9.Rc4 Bxb6 (19.837.347) 42
_____________________________________________________________

18 11:37 -0.14 1...Nd4 2.Bc2 Rc6 3.Kb1 Nxc2 4.Qxc2 Qf8
5.Qd3 f6 6.gxf6 Bxf6 7.Nd5 Bd8
8.Rhg1 Qf7 9.Rc1 (29.504.866) 43

18 14:42 -0.21 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Qe2 Kf8 6.Nd5 Bd8 7.Qb5 Qa8 8.b4 axb4 (37.295.849) 43
_____________________________________________________________

19 34:08 -0.30 1...Nd4 2.Qf2 Nxb3+ 3.Kb1 Nc5 4.Bb5 b6
5.Nd5 Qb7 6.Rhg1 g6 7.Rg2 Kh8
8.Qe1 (87.739.800) 43

19 44:02 -0.31 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Rhg1 Qa8 6.h5 Qa6 7.Qd2 Bd8
8.g6 hxg6 (113.305.500) 43
_____________________________________________________________

20 66:13 -0.25 1...Nd4 2.Qf2 Nxb3+ 3.Kb1 Nc5 4.Bb5 b6
5.Nd5 Qb7 6.Rhg1 g6 7.Rg2 Kh8 8.Qe1 (168.700.155) 43

20 75:00 -0.26 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Qd2 b6 6.h5 Qb7 7.h6 g6 8.Rhg1 Nc5
9.Ka2 Ne6 (190.667.022) 43
_____________________________________________________________

21 127:28 -0.27 1...Nhf4 2.h4 Nxd3+ 3.Qxd3 Ra6 4.Kb1 Rac6
5.Qd2 Qa8 6.h5 Qa6 7.Rhg1 Bd8 8.h6 Bb6
9.Rh1 gxh6 (319.500.612) 42


21 107:48 -0.28 1...Nd4 2.Qf2 Nxb3+ 3.Kb1 Nc5 4.Bb5 b6
5.Nd5 Qb7 6.Rhg1 g6 7.Rg2 Bd8 8.Qh4 (269.734.443) 42



Eelco
Here is the Rybka 3 analysis, gathered from the Arena log:

rqr3k1/1p2bppp/3pn3/p3p1Pn/P3P3/1PNBBP2/1P1Q3P/2KR3R b - - acd 20; acs 3166 ; acn 415572031; ce -38 ; bm Ne6d4; pv Ne6d4 Bd3c2 Rc8c6 Kc1b1 Nd4xc2 Qd2xc2 f7f6 h2h4 Qb8f8 Qc2g2 Qf8f7 Nc3d5 Be7d8 Rh1g1 f6f5 g5g6 h7xg6 Qg2xg6 f5f4 Qg6xf7+ Kg8xf7 Be3f2 Nh5g3 Bf2xg3;