piece-square tables/pseudo-mobility

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

piece-square tables/pseudo-mobility

Postby Roman Hartmann » 14 Aug 2008, 10:02

Hi,
for move ordering and also for evaluation my engine relies on piece-square tables. There is a table for every piece. Depending on the game stage they are different for certain pieces (pawn, king). As I improved my qs lately which is much more accurate now, I'm in the process of adjusting these values to avoid big jumps of the evaluation related to these tables.

Is there any simple rule like -the positional value of a bishop shouldn't exceed 20 cp- or something similar? I'm only talking about the positional value of a certain piece on a certain square without any search or an SEE involved, of course.

Actually I think there are at least three problems related to using piece-square tables:

-they have to be in balance with each other
-the positional value should not exceed a certain value
-the values in each of the table have to be 'smooth' or they will break the search (I suspect that this is the main problem that LMR doesn't work at all for me)

Maybe someone who is using piece square tables would like to give his opinion/comment on this?

Best regards
Roman
User avatar
Roman Hartmann
 
Posts: 155
Joined: 11 Oct 2004, 14:21

Re: piece-square tables/pseudo-mobility

Postby Richard Allbert » 14 Aug 2008, 11:03

Hi Roman,

By qs I assume you mean quiescence search?

I had the same setup as you, and simply made a different ordering function for the qs, just using mvvlva / see(), no other scores.

Regards

Richard
Richard Allbert
 
Posts: 105
Joined: 27 Sep 2004, 11:56
Location: Aschaffenburg, Germany

Re: piece-square tables/pseudo-mobility

Postby Roman Hartmann » 14 Aug 2008, 11:13

Richard Allbert wrote:Hi Roman,

By qs I assume you mean quiescence search?

I had the same setup as you, and simply made a different ordering function for the qs, just using mvvlva / see(), no other scores.

Regards

Richard


Hi Richard,
yes, true, I meant the quiescent search when I wrote qs.

I forgot to write that I use the piece-square tables only to sort the quiet moves and not the capture moves in the quiescent search. For sorting qs-moves I rely as well on mvv/lva.

But my evaluation relies to a great deal on the piece-square tables as well and they work quite well but I'm under the impression that there is a some room for improvement if just those values would be adjusted properly.

best regards
Roman
User avatar
Roman Hartmann
 
Posts: 155
Joined: 11 Oct 2004, 14:21

Re: piece-square tables/pseudo-mobility

Postby Richard Allbert » 15 Aug 2008, 21:31

Well, my opinion (which isn't worth much)

Piece tables are effective with very few other eval terms because the pieces are placed centrally and on generally "good" squares. However, as the eval terms increase, the piece square table influence should be reduced - otherwise they will override the other eval features / exaggerate them.

I've been testing this recently - I took all eval terms out of Lime apart from, pawn structure , and changed the piece tables completely:

Pawns just a small bonus for e4/d4, penaltyfor e2/d2
Rooks +0.05 for being central,
Bishops +0.04 for being on the big diagonals.
Back rank -0.10 for development.

Otherwise, no piece table awards.

Oh, endgame Passer Eval was a simple big bonus with each increasing rank.

The result was a shock - in fixed depth games (to depth 9), with Null reduction reduced to 2, the new "small eval" version scored equal with the old "full eval" version. :shock: over 300 games.

I'm wondering if less could be more here.... :)

Richard
Richard Allbert
 
Posts: 105
Joined: 27 Sep 2004, 11:56
Location: Aschaffenburg, Germany

Re: piece-square tables/pseudo-mobility

Postby Michael Sherwin » 16 Aug 2008, 04:16

Roman Hartmann wrote:Hi,
for move ordering and also for evaluation my engine relies on piece-square tables. There is a table for every piece. Depending on the game stage they are different for certain pieces (pawn, king). As I improved my qs lately which is much more accurate now, I'm in the process of adjusting these values to avoid big jumps of the evaluation related to these tables.

Is there any simple rule like -the positional value of a bishop shouldn't exceed 20 cp- or something similar? I'm only talking about the positional value of a certain piece on a certain square without any search or an SEE involved, of course.

Actually I think there are at least three problems related to using piece-square tables:

-they have to be in balance with each other
-the positional value should not exceed a certain value
-the values in each of the table have to be 'smooth' or they will break the search (I suspect that this is the main problem that LMR doesn't work at all for me)

Maybe someone who is using piece square tables would like to give his opinion/comment on this?

Best regards
Roman


RomiChess uses mostly piece square tables for its eval with a little pawn structure code at the leafs. I have tried countless ways to scale and/or limit these values. They all lead to substantially weaker play.

Here is the critical part of the white bishops eval:

Code: Select all
    wBishopTbl[sq] = PopCnt(moves) * 4 + PopCnt(moves2) * 2 + PopCnt(capts) * 8;
    if(cenRow == 0) wBishopTbl[sq] -= 10;
    if(moves & (D4bit | E4bit | D5bit | E5bit)) wBishopTbl[sq] += 10;
    points = evalHistTblg[WB][sq] / evalHistTbln[WB][sq];
    wBishopTbl[sq] += points/2;


// note: moves2 are all the squares reachable in two moves

It is amazing to me that RomiChess is as strong as she is with such a naive and simple eval.
User avatar
Michael Sherwin
 
Posts: 168
Joined: 21 Jul 2005, 06:10
Location: USA

Re: piece-square tables/pseudo-mobility

Postby Michael Sherwin » 19 Aug 2008, 14:43

Okay, someone make a post as I hate seeing my name for days at a time, every time I visit. :x
User avatar
Michael Sherwin
 
Posts: 168
Joined: 21 Jul 2005, 06:10
Location: USA

Re: piece-square tables/pseudo-mobility

Postby Brian Richardson » 19 Aug 2008, 16:36

Romi's evaluation is far from simple, IMO, not that I would rank it among the more complex evals of other engines.
I think it looks more simple than it really is since it is coded cleanly.

The more complex part of the eval is in the InitEval() [and SumEval()] routines.
The very simple basic Eval() by itself is used in the CaptSearch() or quiesce phase.

Clearly splitting the eval into different phases works, at least quite well for Romi.

PS Now you don't have to look at your name for a while
Brian Richardson
 
Posts: 42
Joined: 01 Oct 2004, 05:22

Re: piece-square tables/pseudo-mobility

Postby Roman Hartmann » 20 Aug 2008, 22:12

Hi Richard,
the reason that I'm still using piece-square tables is that they work so nicely. If I take them out Roce will play even worse. Hard to believe, but tested by me several times. I tried a lot of other stuff in my evaluation but often it would only improve for example the endgame but weaken the middlegame too much. Those tables just work though.

So like you figured out by testing, I also think less code could be more. It's not easy to tune an evaluation with a lot of features. It's Much easier to tune a simple eval, at least that's the idea behind my search for better values for my piece-square table.

So far my tries to adjust the values didn't seem to be too promising but I'm thinking about writing a routine that does that for me. Rightnow it's not more than a rough idea though.

best regards
Roman
User avatar
Roman Hartmann
 
Posts: 155
Joined: 11 Oct 2004, 14:21

Re: piece-square tables/pseudo-mobility

Postby Roman Hartmann » 20 Aug 2008, 22:22

Hi Michael,
thanks for participating in this thread and relieving a secret of Romi. Romi shows just nicely what a simple but well tuned eval could mean for an engine.

Thanks for your code-snippet. Pretty interesting.

Anyway, looks like I have quite some work to do with my eval. I might bring up this thread later again, if my work on the eval should bear any fruit.

best regards
Roman
User avatar
Roman Hartmann
 
Posts: 155
Joined: 11 Oct 2004, 14:21

Re: piece-square tables/pseudo-mobility

Postby Daniel Shawul » 22 Aug 2008, 18:12

My take on evaluation is a bit aggressive. This might be because i am a weak player and would want to get everything out of those eval terms that I know of. For example my engine got good improvment from giving
bigger scores for bishop pairs, rook on 7th,material imbalances etc. Ofcourse that does not mean it works all the time, but accurately evaluating all this known terms might be better. Otherwise things like approximate mobility evaluation (most do counting of possible moves) will swamp those and their effect on the game will be insignificant.

IMO smoothening scores between game phases is not a necessity unless you want your engine to play a boring slowly progressing game. Jumps between game phases are not necessarily bad. Even if you want to, you can't avoid them. For example most don't do king safety eval when queens are gone. What good will it be if you average the score there?
There are many other true/false type of evaluations (like trapped piece evaluation) which can't be averaged. This just does not make sense to me. If somebody explains to me how averaging helps objectively (like reduced nodes to a given search depth), I would ofcourse be willing to reconsider.

Daniel
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Re: piece-square tables/pseudo-mobility

Postby Michael Sherwin » 23 Aug 2008, 03:36

My thinking lately has been about the idea that some evaluation terms should totally trump most other terms. That is the way a strong human player would think--"I don't care about this stuff (multiple terms) at all, because this one condition decides". So, multiple terms can overwhelm the eval and cause the correct eval to be overlooked. But, I am far away from codeing something like this.
User avatar
Michael Sherwin
 
Posts: 168
Joined: 21 Jul 2005, 06:10
Location: USA

Re: piece-square tables/pseudo-mobility

Postby YvesLejeail » 28 Aug 2008, 20:42

I think you are right, strong players know immediatly what is important:
- no needs to care about pawn structure if you are under a heavy attack
or if you are a Rook behind
- but if the material is equal and if your king is well defended, other
positionals terms have to be considered (with the help of PST for instance, as it is the subject of the topic ).
This may be possible to do, if you evaluate all the terms (I don't do that though), try to normalize them.

An other thing that strong chess player do is that they think in terms of simplification of the position (am I winning if all the pieces are exchanged, or am I winning if I can exchange this particular piece, am I drawing if I exchange my rooks and my queen,...). This is an other point I would like to have in my engine :wink:
Yves
User avatar
YvesLejeail
 
Posts: 48
Joined: 03 Aug 2005, 17:36
Location: Pertuis, France

Re: piece-square tables/pseudo-mobility

Postby Uri Blass » 29 Aug 2008, 07:48

Michael Sherwin wrote:
Roman Hartmann wrote:Hi,
for move ordering and also for evaluation my engine relies on piece-square tables. There is a table for every piece. Depending on the game stage they are different for certain pieces (pawn, king). As I improved my qs lately which is much more accurate now, I'm in the process of adjusting these values to avoid big jumps of the evaluation related to these tables.

Is there any simple rule like -the positional value of a bishop shouldn't exceed 20 cp- or something similar? I'm only talking about the positional value of a certain piece on a certain square without any search or an SEE involved, of course.

Actually I think there are at least three problems related to using piece-square tables:

-they have to be in balance with each other
-the positional value should not exceed a certain value
-the values in each of the table have to be 'smooth' or they will break the search (I suspect that this is the main problem that LMR doesn't work at all for me)

Maybe someone who is using piece square tables would like to give his opinion/comment on this?

Best regards
Roman


RomiChess uses mostly piece square tables for its eval with a little pawn structure code at the leafs. I have tried countless ways to scale and/or limit these values. They all lead to substantially weaker play.

Here is the critical part of the white bishops eval:

Code: Select all
    wBishopTbl[sq] = PopCnt(moves) * 4 + PopCnt(moves2) * 2 + PopCnt(capts) * 8;
    if(cenRow == 0) wBishopTbl[sq] -= 10;
    if(moves & (D4bit | E4bit | D5bit | E5bit)) wBishopTbl[sq] += 10;
    points = evalHistTblg[WB][sq] / evalHistTbln[WB][sq];
    wBishopTbl[sq] += points/2;


// note: moves2 are all the squares reachable in two moves

It is amazing to me that RomiChess is as strong as she is with such a naive and simple eval.


I think that RomiChess is not so strong.
My opinion is that if you modify Strelka's evaluation to piece square table evaluation you may get a stronger program.

I have a piece square table version of strelka and I found that it is at least stronger than Joker(did not test it against RomiChess)

The piece square version of strelka has not optimized piece square tables
because I did not change the original piece square table values.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: piece-square tables/pseudo-mobility

Postby Michael Sherwin » 30 Aug 2008, 04:11

Uri Blass wrote:
Michael Sherwin wrote:
Roman Hartmann wrote:Hi,
for move ordering and also for evaluation my engine relies on piece-square tables. There is a table for every piece. Depending on the game stage they are different for certain pieces (pawn, king). As I improved my qs lately which is much more accurate now, I'm in the process of adjusting these values to avoid big jumps of the evaluation related to these tables.

Is there any simple rule like -the positional value of a bishop shouldn't exceed 20 cp- or something similar? I'm only talking about the positional value of a certain piece on a certain square without any search or an SEE involved, of course.

Actually I think there are at least three problems related to using piece-square tables:

-they have to be in balance with each other
-the positional value should not exceed a certain value
-the values in each of the table have to be 'smooth' or they will break the search (I suspect that this is the main problem that LMR doesn't work at all for me)

Maybe someone who is using piece square tables would like to give his opinion/comment on this?

Best regards
Roman


RomiChess uses mostly piece square tables for its eval with a little pawn structure code at the leafs. I have tried countless ways to scale and/or limit these values. They all lead to substantially weaker play.

Here is the critical part of the white bishops eval:

Code: Select all
    wBishopTbl[sq] = PopCnt(moves) * 4 + PopCnt(moves2) * 2 + PopCnt(capts) * 8;
    if(cenRow == 0) wBishopTbl[sq] -= 10;
    if(moves & (D4bit | E4bit | D5bit | E5bit)) wBishopTbl[sq] += 10;
    points = evalHistTblg[WB][sq] / evalHistTbln[WB][sq];
    wBishopTbl[sq] += points/2;


// note: moves2 are all the squares reachable in two moves

It is amazing to me that RomiChess is as strong as she is with such a naive and simple eval.


I think that RomiChess is not so strong.
My opinion is that if you modify Strelka's evaluation to piece square table evaluation you may get a stronger program.

I have a piece square table version of strelka and I found that it is at least stronger than Joker(did not test it against RomiChess)

The piece square version of strelka has not optimized piece square tables
because I did not change the original piece square table values.

Uri


Uri,

RomiChess is not so strong compared to Strelka, however, RomiChess is quite strong compared to alot of other engines. So, 'strong' is a relative term. Take a very strong man and put him into a cage with an angry gorrilla ...

So anyway why the attack? Is it the language barrier at work?

However, you make a very interesting point about Strelka and piece square tables that deserves further testing. So, why don't you test RomiChess against the stripped down Strelka? :D
User avatar
Michael Sherwin
 
Posts: 168
Joined: 21 Jul 2005, 06:10
Location: USA

Re: piece-square tables/pseudo-mobility

Postby Uri Blass » 30 Aug 2008, 11:21

Michael,
I tested RomiChess against the stripped down Strelka

Strelka won 9-1
It seems that RomiChess is not materialistic enough and I guess that possible improvement in RomiChess evaluation may be to have average between the normal evaluation and only material evaluation.

Here are some games of the match(including the only win of Romi)


[Event "URI-AMD, Blitz:1'+1""]
[Site "URI-AMD"]
[Date "2008.08.30"]
[Round "4"]
[White "Strelka 2.0 W"]
[Black "RomiChess"]
[Result "0-1"]
[ECO "A00"]
[Annotator "-0.05;-0.22"]
[PlyCount "170"]
[TimeControl "60+1"]

{W=13.8 ply; 1,763kN/s B=13.9 ply; 1,827kN/s} 1. a4 {Both last book move} Nf6
{0.01/1 0} 2. Nf3 {-0.05/14 5} e5 {(Nb8-c6) -0.22/13 4} 3. Nxe5 {
(e2-e3) 0.48/13 2} d6 {(Bf8-d6) -0.13/13 4} 4. Nd3 {0.88/13 2} Nc6 {
(Bf8-e7) -0.22/13 4} 5. Nc3 {0.88/13 3} d5 {-0.32/12 3} 6. e3 {
(b2-b3) 0.85/13 2} d4 {(a7-a6) -0.52/12 3} 7. Nb5 {(Nc3-e2) 0.95/10 1} a6 {
(d4xe3) -0.44/14 3} 8. Nxd4 {0.84/11 1} Nxd4 {-0.44/14 3} 9. exd4 {
(Qd1-e2) 0.82/12 1} Qxd4 {-0.34/13 3} 10. Qf3 {(Qd1-e2+) 0.85/12 4} Bd6 {
(Bf8-e7) -0.45/12 3} 11. Qe3+ {0.89/12 2} Qe4 {(Qd4xe3+) -0.08/12 3} 12. Qxe4+
{0.93/13 3} Nxe4 {0.40/14 3} 13. b3 {0.93/13 1} O-O {(Bc8-f5) 0.10/12 2} 14. f3
{(Bc1-b2) 0.98/13 2} Ng5 {(Ne4-f6) -0.03/13 3} 15. Ba3 {1.02/13 2} Re8+ {
(Bd6xa3) -0.11/13 2} 16. Kf2 {1.08/12 1} Bxa3 {(Ng5-e6) -0.13/13 2} 17. Rxa3 {
1.08/13 2} Bf5 {(g7-g6) 0.09/12 2} 18. h4 {(Nd3-c5) 1.07/13 1} Ne6 {0.26/14 2}
19. g4 {1.07/14 2} Bg6 {(Bf5xd3) 0.28/13 2} 20. h5 {1.10/13 1} Bxd3 {0.38/13 2}
21. Bxd3 {1.10/13 1} Rad8 {(g7-g5) 0.61/12 3} 22. Kg3 {1.09/12 2} Nc5 {
(g7-g5) 0.25/14 2} 23. b4 {1.11/13 2} Nxd3 {0.20/15 2} 24. cxd3 {
(Ra3xd3) 1.09/14 2} Re2 {(f7-f6) 0.17/13 2} 25. Rd1 {1.07/14 2} g6 {
(Kg8-f8) 0.10/13 2} 26. h6 {1.06/14 3} c6 {(f7-f6) 0.17/13 2} 27. Rc3 {
0.27/16 12} Rd5 {(Re2-e6) 0.12/13 1} 28. f4 {1.08/12 0} f6 {(Re2-e6) -0.16/14 2
} 29. a5 {0.08/14 3} Kf7 {(Rd5-b5) -0.44/14 2} 30. Ra3 {0.02/14 2} Ke7 {
(Rd5-b5) -0.63/14 2} 31. Rb3 {0.00/14 2} Kd6 {(Rd5-b5) -0.83/14 2} 32. Rc3 {
0.00/15 1} Rd4 {-0.65/14 2} 33. Rb3 {0.00/15 1} g5 {(Rd4-d5) -0.53/15 2} 34.
Kf3 {(Rd1-f1) -0.31/15 1} Rh2 {-1.27/15 2} 35. Kg3 {-1.03/16 2} Rxh6 {
-1.36/15 2} 36. fxg5 {-1.06/16 1} fxg5 {-1.68/15 2} 37. Re1 {-1.02/16 1} Rf4 {
(Rh6-h4) -1.32/15 2} 38. Re4 {-0.46/14 3} Rhf6 {(Rf4-f1) -1.32/14 1} 39. Rxf4 {
-1.17/16 6} Rxf4 {-1.26/15 1} 40. Rb1 {-1.31/17 2} Rd4 {-1.30/15 2} 41. Rb3 {
-1.36/17 2} Kd5 {(Kd6-e5) -1.66/16 1} 42. Kf3 {(Kg3-h3) -1.44/17 2} Rf4+ {
-1.85/16 1} 43. Ke2 {(Kf3-g3) -1.41/17 1} Rxg4 {-4.04/14 2} 44. Kf3 {-1.44/17 1
} h5 {(Rg4-h4) -4.52/15 2} 45. Ke3 {-2.38/17 4} h4 {(Rg4-g3+) -4.81/15 1} 46.
Rc3 {(Rb3-b1) -2.37/16 1} Rxb4 {(h4-h3) -5.34/14 1} 47. Rc1 {-2.69/15 3} Rb5 {
(Rb4-g4) -5.12/14 1} 48. Ra1 {-2.32/15 1} Kd6 {(h4-h3) -5.27/14 1} 49. d4 {
-2.33/13 1} Rf5 {(g5-g4) -5.17/14 1} 50. Rb1 {-2.27/15 1} Kc7 {-5.27/15 1} 51.
Ra1 {-2.33/15 1} g4 {(h4-h3) -5.47/15 1} 52. Ke4 {-2.43/14 1} Rf2 {
(Rf5-d5) -5.47/15 2} 53. Ke3 {-2.86/14 1} g3 {(Rf2-f3+) -5.74/15 1} 54. Rg1 {
-3.47/14 2} Rf5 {(Rf2-h2) -7.34/13 1} 55. Ke4 {(d2-d3) -3.34/14 1} Rxa5 {
-7.94/14 1} 56. Kf4 {(d2-d3) -3.96/16 6} Rd5 {-8.54/14 1} 57. Ke4 {-4.47/15 1}
b6 {(Rd5-g5) -8.88/14 1} 58. d3 {-3.51/14 1} a5 {(Rd5-d7) -9.10/15 1} 59. Ke3 {
-4.37/15 2} a4 {(Rd5-d8) -9.40/15 1} 60. Ke4 {-3.42/13 1} Kd6 {
(Rd5-d7) -9.72/14 1} 61. Kf4 {(Ke4-e3) -4.52/15 1} Rxd4+ {-10.13/14 2} 62. Ke3
{-4.73/15 1} Rb4 {(Kd6-d5) -10.19/14 1} 63. Kf3 {(Rg1-a1) -4.63/14 1} b5 {
(Kd6-e5) -10.40/14 1} 64. Rg2 {-4.62/15 1} c5 {(Kd6-e5) -10.82/14 1} 65. Rg1 {
(Rg2-a2) -4.76/14 1} Rd4 {(Kd6-d5) -11.11/14 1} 66. Kg2 {-4.54/13 1} Rxd3 {
-11.73/15 1} 67. Rb1 {(Kg2-h3) -5.58/13 1} b4 {-12.44/14 1} 68. Rh1 {
(Kg2-h3) -5.61/13 1} Rd2+ {(Rd3-d4) -13.80/15 2} 69. Kf3 {-9.06/16 1} g2 {
-14.12/16 1} 70. Rg1 {-9.16/17 1} h3 {-14.12/16 1} 71. Kg3 {-13.21/16 1} c4 {
(Rd2-d3+) -15.04/17 2} 72. Kxh3 {(Kg3-h2) -12.86/13 1} c3 {(a4-a3) -15.06/13 2}
73. Kg4 {(Rg1-e1) -17.93/12 1} c2 {-16.97/13 1} 74. Kf5 {-18.32/12 1} b3 {
(Rd2-d1) -25.01/13 1} 75. Re1 {(Kf5-e4) -22.97/9 1} b2 {-27.58/12 1} 76. Re6+ {
-27.14/9 3} Kd7 {(Kd6-c5) -28.10/11 1} 77. Rh6 {(Kf5-f6) -38.09/8 1} b1=Q {
(c2-c1Q) -39.19/11 1} 78. Rh7+ {-#6/7 0} Kd6 {(Kd7-c6) -39.21/11 1} 79. Rh6+ {
-#8/7 1} Kd5 {(Kd6-c5) -39.23/10 1} 80. Rh5 {(Rh6-h7) -#6/6 0} c1=Q+ {
-39.55/7 1} 81. Kg5 {0.01/5 0} g1=Q+ {-39.87/6 1} 82. Kh6+ {(Kg5-h4+) 0.01/4 0}
Kd6 {-#6/4 0} 83. Rg5 {0.01/3 0} Qh1+ {-#3/5 0} 84. Kg7 {0.01/2 0} Qc7+ {
-#2/4 0} 85. Kg8 {0.01/0 0} Qbb8# {-#1/4 0} 0-1

[Event "URI-AMD, Blitz:1'+1""]
[Site "URI-AMD"]
[Date "2008.08.30"]
[Round "6"]
[White "Strelka 2.0 W"]
[Black "RomiChess"]
[Result "1-0"]
[ECO "A01"]
[Annotator "0.02;-0.39"]
[PlyCount "345"]
[TimeControl "60+1"]

{W=12.2 ply; 1,721kN/s B=13.0 ply; 1,876kN/s} 1. b3 {Both last book move} Nc6
{0.01/1 0} 2. Nf3 {0.02/14 6} e5 {-0.39/13 4} 3. e4 {-0.02/13 3} Nf6 {
-0.42/13 4} 4. Nc3 {-0.01/13 3} Bc5 {-0.34/13 5} 5. Bc4 {-0.03/13 5} d6 {
(0-0) -0.38/11 3} 6. O-O {(d2-d3) -0.05/11 1} Bg4 {-0.32/12 3} 7. d3 {
-0.04/11 1} Bxf3 {(0-0) -0.69/12 3} 8. gxf3 {(Qd1xf3) -0.02/12 2} Bd4 {
-1.28/13 3} 9. Bd2 {-0.26/12 2} Na5 {(Nf6-h5) -0.99/12 3} 10. Rb1 {0.07/12 3}
Bxc3 {(0-0) -0.54/11 2} 11. Bxc3 {0.15/11 1} Nxc4 {(Na5-c6) -0.25/13 2} 12.
bxc4 {0.23/12 1} Rb8 {-0.11/13 2} 13. d4 {(f3-f4) 0.16/11 3} Qe7 {
(Nf6-d7) -0.83/12 3} 14. dxe5 {(Qd1-d2) 0.23/12 1} dxe5 {-0.35/12 2} 15. Rb5 {
0.19/12 4} c5 {-0.09/12 2} 16. Qa1 {0.25/12 1} Nd7 {-0.18/13 3} 17. Rd1 {
0.21/12 2} Qg5+ {(0-0) -0.20/12 3} 18. Kh1 {0.22/11 1} Qf4 {(Qg5-h5) -0.10/12 3
} 19. Rd3 {0.42/12 3} b6 {0.01/11 2} 20. Rb3 {(Rb5-b1) 0.40/12 4} Rd8 {
(Rb8-b7) -0.03/11 2} 21. Qd1 {0.45/12 1} Rg8 {(Ke8-e7) 0.05/12 2} 22. Rd5 {
(Rb3-a3) 0.76/12 1} Qg5 {(Ke8-e7) 0.18/12 2} 23. f4 {(Rb3-a3) 1.04/13 1} Qxf4 {
(Qg5-h4) 0.35/13 2} 24. Bxe5 {2.05/13 1} Qxe5 {0.36/13 1} 25. Rxe5+ {2.04/13 1}
Nxe5 {0.68/15 2} 26. Qh5 {2.74/14 2} Nxc4 {0.97/14 2} 27. Rc3 {3.14/14 4} Na5 {
1.70/12 2} 28. Rf3 {(Qh5-e5+) 3.20/13 2} Rf8 {2.31/12 2} 29. Qe5+ {
(Kh1-g2) 3.17/12 1} Kd7 {2.31/6 0} 30. Qxg7 {3.22/11 0} Ke7 {2.36/12 2} 31.
Qe5+ {3.25/11 1} Kd7 {2.36/6 0} 32. Kg2 {(Rf3-d3+) 3.20/12 1} Kc8 {
(Na5-c6) 2.17/10 2} 33. Rf6 {(Qe5-f5+) 3.22/11 3} Rd7 {1.96/12 2} 34. Qf5 {
3.21/12 1} h5 {2.06/12 2} 35. e5 {(Kg2-h3) 3.49/12 3} Kc7 {2.96/11 1} 36. Qxh5
{(Rf6xf7) 3.50/11 1} Nc4 {(Na5-b7) 2.73/11 2} 37. Rf4 {3.49/12 1} Na5 {
3.56/12 1} 38. Kh3 {(Kg2-f1) 3.39/12 1} Re7 {2.92/13 2} 39. Rf6 {
(e5-e6) 3.62/12 2} Nc4 {(Kc7-b8) 3.08/13 2} 40. e6 {3.70/12 1} Nd6 {3.26/13 2}
41. Qh7 {3.59/12 1} Kd8 {3.15/13 2} 42. exf7 {3.62/12 1} Nxf7 {3.23/13 2} 43.
Kg2 {3.66/13 2} Rd7 {(Kd8-e8) 3.56/12 2} 44. Qg7 {(Kg2-f3) 4.22/13 1} Ke8 {
3.62/12 1} 45. Re6+ {(f2-f4) 4.28/13 1} Re7 {4.00/15 2} 46. Qf6 {4.28/13 2}
Rg8+ {4.07/15 2} 47. Kf1 {4.34/15 1} Rxe6 {4.29/15 1} 48. Qxe6+ {4.33/14 1} Kf8
{4.31/16 2} 49. Qd7 {4.35/14 1} Rg6 {4.29/14 1} 50. Qxa7 {4.35/13 1} Rh6 {
(Rg6-e6) 4.32/12 1} 51. a4 {(Qa7-b8+) 4.41/12 1} Ke8 {(Kf8-g7) 4.43/11 1} 52.
Kg2 {(f2-f3) 4.46/11 3} Rg6+ {4.11/11 2} 53. Kh3 {4.47/12 1} Rh6+ {4.43/11 1}
54. Kg4 {4.46/13 1} Ne5+ {4.45/12 2} 55. Kg5 {4.43/13 2} Nf7+ {
(Rh6-g6+) 4.13/11 1} 56. Kf5 {4.52/11 0} Nd6+ {4.34/11 1} 57. Kg4 {4.50/12 1}
Rg6+ {(Nd6-c4) 4.36/12 2} 58. Kh5 {4.99/13 2} Rf6 {4.47/13 2} 59. Qxb6 {
4.99/12 0} Kd7 {5.13/12 1} 60. Qa7+ {4.92/12 1} Ke6 {4.86/13 1} 61. Qa5 {
4.95/12 1} Rf4 {4.95/12 1} 62. Qc3 {(h2-h3) 4.35/13 8} Rxa4 {(Nd6-e4) 4.75/11 1
} 63. Qxc5 {5.15/10 0} Re4 {5.26/12 2} 64. Qa3 {(Qc5-b6) 5.23/11 2} Kd5 {
(Re4-c4) 5.47/11 1} 65. Kg5 {5.25/11 3} Nf7+ {(Re4-e5+) 5.32/10 1} 66. Kf6 {
5.27/12 1} Nd6 {5.26/12 2} 67. Qa5+ {5.27/12 2} Kc6 {5.42/12 1} 68. f3 {
5.27/12 2} Rh4 {(Re4-d4) 5.44/12 1} 69. Qa6+ {5.25/11 1} Kc5 {5.38/11 1} 70.
Qa3+ {5.25/12 3} Kd5 {(Kc5-c6) 5.40/12 1} 71. Qa2+ {5.27/11 1} Kc5 {
(Rh4-c4) 5.48/12 2} 72. c3 {5.27/12 1} Rh3 {(Kc5-c6) 5.54/12 2} 73. Qa5+ {
5.33/11 1} Kc6 {5.52/13 1} 74. Qa8+ {(Qa5-a4+) 5.33/12 2} Kc5 {5.50/13 1} 75.
Qa7+ {5.31/12 2} Kc6 {5.50/13 1} 76. Qa4+ {5.31/12 1} Kd5 {5.90/14 1} 77. Qd4+
{(Qa4-f4) 5.30/11 1} Kc6 {5.44/6 0} 78. Qf4 {5.28/12 1} Rh8 {5.90/12 2} 79. Ke5
{5.29/11 1} Re8+ {(Rh8-h5+) 5.71/11 1} 80. Kd4 {5.23/12 1} Rh8 {
(Re8-a8) 5.80/12 1} 81. Kd3 {5.27/12 1} Rh5 {5.90/11 1} 82. Qa4+ {5.25/11 1}
Kb6 {6.03/12 1} 83. Qa2 {5.25/11 1} Kc6 {(Rh5-f5) 5.72/12 1} 84. Kd4 {5.24/12 2
} Rh4+ {(Nd6-b5+) 5.57/10 1} 85. Ke5 {5.26/12 1} Rh5+ {5.59/11 1} 86. Kf4 {
5.25/12 1} Rh4+ {(Rh5-c5) 5.49/11 1} 87. Kg5 {5.24/11 0} Rc4 {5.49/11 1} 88.
Qa8+ {5.24/11 1} Kc5 {5.41/12 1} 89. Qa3+ {(Qa8-a7+) 5.23/11 1} Kc6 {5.20/12 1}
90. Kg6 {(h2-h4) 5.24/12 1} Nb5 {(Kc6-b6) 4.88/11 1} 91. Qa6+ {5.21/11 0} Kc5 {
4.82/13 1} 92. Qc8+ {(h2-h4) 5.20/9 0} Kd5 {4.91/13 1} 93. Qf5+ {4.83/11 2} Kc6
{4.91/13 1} 94. Qe6+ {4.83/9 1} Kc5 {4.97/13 1} 95. Qe3+ {4.68/10 1} Kc6 {
4.82/12 1} 96. Qe8+ {4.39/10 3} Kb6 {4.80/13 1} 97. Qb8+ {(h2-h4) 4.39/10 2}
Kc5 {(Kb6-c6) 4.97/12 1} 98. Qf8+ {(Qb8-e5+) 4.38/9 1} Kd5 {(Kc5-c6) 4.82/12 1}
99. Qf7+ {(Qf8-d8+) 4.38/9 1} Kc5 {4.84/13 1} 100. Qe7+ {4.39/9 1} Kc6 {
(Kc5-b6) 4.86/13 1} 101. Qf6+ {4.39/10 1} Kd5 {(Kc6-c5) 4.84/13 1} 102. Qd8+ {
4.39/10 2} Kc5 {(Kd5-c6) 4.82/12 1} 103. Kf5 {4.23/9 1} Rxc3 {
(Nb5xc3) 4.59/10 1} 104. Qg5 {(f3-f4) 4.19/9 1} Kc4 {(Rc3-c2) 4.54/10 1} 105.
Ke5 {(Qg5-g8+) 4.20/11 1} Kb3 {(Rc3-d3) 5.07/10 1} 106. Qg1 {4.21/11 1} Kb4 {
(Kb3-c4) 4.88/10 1} 107. Qe1 {(h2-h4) 4.23/12 1} Kb3 {(Kb4-c5) 5.07/11 1} 108.
Qb1+ {4.24/12 1} Kc4 {5.09/12 1} 109. Qe4+ {4.23/12 1} Kb3 {5.11/13 2} 110.
Qd5+ {(h2-h4) 4.23/13 1} Kb4 {4.91/12 1} 111. Qd2 {4.23/13 1} Kb3 {
(Kb4-a4) 4.88/12 1} 112. Kd5 {(h2-h4) 4.22/12 2} Nc7+ {4.80/10 1} 113. Ke4 {
4.21/12 1} Rc4+ {4.88/11 1} 114. Kf5 {4.20/13 1} Rc5+ {(Nc7-b5) 4.82/11 1} 115.
Kg4 {4.21/11 1} Nd5 {5.07/11 1} 116. Qd3+ {(h2-h4) 4.20/11 1} Kb4 {
(Nd5-c3) 4.96/12 1} 117. f4 {(h2-h4) 4.20/12 1} Nf6+ {4.95/11 1} 118. Kh4 {
4.20/13 1} Rd5 {(Nf6-d5) 5.00/12 1} 119. Qb1+ {(Qd3-g6) 4.26/11 1} Kc5 {
4.89/11 1} 120. Qc2+ {(f4-f5) 4.24/11 1} Kd6 {4.68/12 1} 121. Qc8 {
(f4-f5) 4.26/12 1} Rd2 {(Rd5-h5+) 4.63/10 1} 122. Qa6+ {4.32/10 1} Ke7 {
5.02/12 1} 123. Qa7+ {4.34/10 0} Rd7 {5.01/13 1} 124. Qe3+ {4.40/12 1} Kf7 {
5.18/14 1} 125. f5 {4.43/14 1} Re7 {5.41/13 1} 126. Qb3+ {4.42/14 3} Kg7 {
(Kf7-f8) 5.41/13 1} 127. Qg3+ {4.49/14 1} Kf8 {5.68/13 1} 128. Qg6 {4.49/14 1}
Nd7 {(Re7-h7+) 6.20/13 1} 129. Qd6 {4.81/12 1} Ke8 {(Kf8-f7) 5.88/12 1} 130. f6
{(Kh4-g5) 4.81/12 1} Rh7+ {6.29/11 1} 131. Kg5 {3.57/13 1} Kd8 {
(Rh7-f7) 6.91/14 1} 132. Qd5 {(Kg5-g6) 5.44/11 1} Rxh2 {5.42/14 1} 133. f7 {
7.25/11 1} Ke7 {6.78/13 1} 134. Qe4+ {(f7-f8Q+) 7.31/11 1} Kd8 {5.48/13 1} 135.
Qe8+ {(Qe4-d4) 7.35/11 1} Kc7 {4.52/6 0} 136. f8=Q {(Kg5-f4) 7.37/12 1} Rg2+ {
7.71/13 2} 137. Kh4 {7.41/12 1} Nxf8 {7.71/13 1} 138. Qe5+ {7.45/12 1} Kc6 {
7.80/13 1} 139. Qe4+ {7.41/9 0} Kc5 {7.93/14 1} 140. Qxg2 {7.51/11 0} Ne6 {
7.95/14 2} 141. Qd2 {7.60/13 1} Kc6 {8.44/14 1} 142. Kg4 {7.76/12 1} Nc5 {
(Kc6-c5) 8.44/14 1} 143. Kf5 {7.93/13 1} Nd7 {8.59/14 1} 144. Qc2+ {7.93/11 1}
Kd6 {(Kc6-b5) 8.66/13 1} 145. Qd3+ {7.93/14 1} Kc6 {(Kd6-c7) 8.68/13 1} 146.
Qf3+ {(Qd3-e4+) 7.93/10 1} Kd6 {(Kc6-c5) 8.66/15 1} 147. Qf4+ {
(Kf5-e4) 7.92/10 1} Kc6 {8.85/14 1} 148. Qe4+ {7.93/11 1} Kc5 {8.85/15 1} 149.
Qe3+ {7.93/13 3} Kc6 {(Kc5-d6) 8.85/15 1} 150. Qe6+ {7.93/12 1} Kc7 {8.91/16 1}
151. Qc4+ {(Qe6-d5) 7.93/13 2} Kd6 {8.89/15 1} 152. Qd4+ {7.93/12 1} Kc6 {
(Kd6-c7) 8.70/15 1} 153. Qa4+ {7.85/10 1} Kc7 {(Kc6-d6) 8.72/16 1} 154. Qb4 {
(Qa4-a6) 7.93/11 1} Kc6 {(Nd7-b6) 8.57/15 1} 155. Qc3+ {7.84/9 1} Kd5 {
(Kc6-d6) 8.68/15 1} 156. Qb3+ {7.91/10 1} Kc6 {(Kd5-c5) 8.70/15 1} 157. Qe3 {
(Qb3-a3) 7.84/12 1} Nc5 {8.63/14 1} 158. Ke5 {8.08/14 1} Nd7+ {8.73/13 1} 159.
Kd4 {(Ke5-e4) 8.13/16 1} Kd6 {8.79/15 2} 160. Qe4 {8.36/15 1} Kc7 {8.93/15 1}
161. Qe6 {10.87/14 1} Nb8 {9.19/14 1} 162. Qe5+ {(Qe6-c4+) 10.66/10 1} Kc8 {
(Kc7-b7) 9.23/14 1} 163. Qc5+ {(Kd4-d5) 10.87/13 3} Kb7 {9.70/14 1} 164. Qd5+ {
(Kd4-d5) 8.40/9 1} Kb6 {9.66/15 2} 165. Qd6+ {(Qd5-b3+) 10.98/13 1} Kb7 {
9.68/14 1} 166. Kc4 {(Qd6-b4+) 11.18/15 1} Na6 {10.16/14 1} 167. Qd5+ {
(Qd6-e7+) 11.18/14 2} Ka7 {(Kb7-c7) 10.62/15 2} 168. Qc6 {(Qd5-d4+) #7/11 0}
Kb8 {#9/12 0} 169. Qxa6 {#6/9 0} Kc7 {0.01/1 0} 170. Kd5 {#4/6 0} Kd7 {
(Kc7-d8) 0.01/1 0} 171. Qb7+ {0.01/3 0} Ke8 {0.01/1 0} 172. Ke6 {0.01/2 0} Kd8
{0.01/1 0} 173. Qb8# {0.01/0 0} 1-0



[Event "URI-AMD, Blitz:1'+1""]
[Site "URI-AMD"]
[Date "2008.08.30"]
[Round "10"]
[White "Strelka 2.0 W"]
[Black "RomiChess"]
[Result "1-0"]
[ECO "A00"]
[Annotator "-0.21;-0.10"]
[PlyCount "113"]
[TimeControl "60+1"]

{W=11.2 ply; 1,267kN/s B=11.7 ply; 1,598kN/s} 1. c3 {Both last book move} e6 {
0.01/1 0} 2. Nf3 {-0.21/13 2} d5 {(Ng8-f6) -0.10/13 4} 3. g3 {
(d2-d4) -0.10/12 2} Nf6 {(Nb8-c6) -0.29/13 4} 4. Bg2 {-0.18/12 2} Bd6 {
(Nb8-c6) -0.53/13 4} 5. Na3 {-0.06/13 3} Bd7 {(0-0) -0.17/12 5} 6. O-O {
-0.02/12 4} c5 {(Nb8-c6) -0.49/11 3} 7. d4 {0.00/11 2} Qb6 {(0-0) -0.22/12 5}
8. dxc5 {0.00/11 2} Bxc5 {-0.18/12 3} 9. b4 {0.09/12 2} Be7 {
(Bc5xf2+) -0.20/11 3} 10. Be3 {(Nf3-e5) 0.08/12 5} Qa6 {-0.91/12 3} 11. Nc2 {
0.13/12 3} Ba4 {-1.06/12 2} 12. Nfd4 {0.05/12 4} O-O {(Nb8-d7) -1.16/12 3} 13.
Qd2 {(Qd1-d3) 0.09/11 1} Rc8 {(Nb8-d7) -1.15/11 2} 14. Ne1 {0.16/11 3} Nbd7 {
(Nb8-c6) -0.92/11 2} 15. Bg5 {(Ne1-d3) 0.12/11 1} Ne5 {-0.96/12 2} 16. Nd3 {
0.06/10 1} Nc4 {(Be7-d6) -0.90/12 2} 17. Qc1 {(Qd2-e1) 0.02/11 3} Qb6 {
(Ba4-c6) -0.84/11 2} 18. Bf4 {(Ra1-b1) -0.02/10 3} Kh8 {(Ba4-d7) -1.02/10 2}
19. Rb1 {0.16/10 4} Qa6 {(Kh8-g8) -0.78/11 2} 20. f3 {0.16/11 5} Qb6 {
(Ba4-d7) -1.21/11 3} 21. Rf2 {(e2-e4) 0.17/10 1} Nh5 {(Kh8-g8) -1.16/11 3} 22.
Bg5 {0.27/11 1} Bd6 {(Be7-f6) -1.03/12 3} 23. f4 {0.17/10 1} Kg8 {
(h7-h6) -0.83/10 2} 24. Nb2 {(Bg5-h4) 0.08/10 1} Nxb2 {(Qb6-a6) -0.85/12 2} 25.
Qxb2 {(Bg5-h4) 0.21/10 0} h6 {(Nh5-f6) -0.73/12 2} 26. Bh4 {0.17/10 0} Qc7 {
(Nh5-f6) -0.45/11 2} 27. Rf3 {0.14/12 2} Be7 {(e6-e5) -0.71/11 2} 28. Bxe7 {
0.32/11 0} Qxe7 {-0.76/12 1} 29. Re3 {(Rf3-d3) 0.26/12 3} Nf6 {-0.94/11 1} 30.
Bf3 {(Re3-d3) 0.24/11 1} Rc4 {(Qe7-d6) -0.99/11 2} 31. Qd2 {(Re3-d3) 0.30/10 2}
Rac8 {(Qe7-d6) -1.37/11 1} 32. Rc1 {0.26/11 2} Qc7 {(Qe7-d7) -1.19/11 2} 33. a3
{0.12/11 2} h5 {(g7-g5) -1.24/11 2} 34. Kg2 {0.12/11 3} b6 {(Nf6-e4) -1.44/10 1
} 35. Qd3 {(Re3-d3) 0.19/11 3} a5 {(Ba4-d7) -1.41/11 2} 36. Qd2 {0.13/11 2} g6
{(a5xb4) -1.98/11 2} 37. Qd3 {(b4xa5) -0.05/12 8} Kh7 {(h5-h4) -1.79/10 1} 38.
h4 {-0.37/12 5} axb4 {-1.37/12 4} 39. axb4 {-0.43/12 1} Rxb4 {-1.28/11 2} 40.
f5 {0.02/12 2} gxf5 {-0.96/11 1} 41. Nxf5 {0.03/11 1} Ra8 {(Ba4-b5) -0.55/10 1}
42. Ne7+ {2.01/13 7} Kh8 {0.18/12 1} 43. cxb4 {2.01/13 1} Qxc1 {0.68/13 2} 44.
Qd4 {1.94/12 1} Kg7 {0.87/12 1} 45. Re5 {2.29/11 1} Bc2 {(Kg7-f8) 0.51/11 1}
46. Rg5+ {3.60/10 1} Bg6 {0.21/11 1} 47. Nxg6 {4.07/10 1} fxg6 {3.71/11 1} 48.
Qd3 {4.20/11 1} Ne4 {(Qc1-a1) 4.23/11 1} 49. Bxe4 {5.17/10 1} Kf8 {4.31/10 1}
50. Qf3+ {(Be4xg6) 5.30/10 1} Ke7 {4.83/12 1} 51. Rxg6 {7.57/10 1} Qb2 {
(Ra8-e8) 6.42/11 1} 52. Bxd5 {(Rg6xe6+) 15.89/9 1} exd5 {(Qb2-e5) 8.12/9 1} 53.
Qe3+ {0.01/5 0} Kf8 {9.20/11 1} 54. Qf4+ {(Qe3-e6) 0.01/4 0} Ke7 {#6/3 0} 55.
Qd6+ {0.01/3 0} Kf7 {0.01/1 0} 56. Qe6+ {0.01/0 0} Kf8 {0.01/1 0} 57. Rg8# {
0.01/0 0} 1-0
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: piece-square tables/pseudo-mobility

Postby Uri Blass » 30 Aug 2008, 11:59

I can add that at fixed depth
Romi depth 2 is only slightly better than strelka stupid depth 1.

Here is an example for typical depth 1 tactics when romi needs 2 plies

r6r/2N3pp/p7/1pb1P2k/8/4R2P/PP3KP1/5R2 b - - 0 23

Romi needs 2 plies to find Raf8+ when most programs can see it at 1 ply.

Uri
User avatar
Uri Blass
 
Posts: 727
Joined: 09 Oct 2004, 05:59
Location: Tel-Aviv

Re: piece-square tables/pseudo-mobility

Postby Michael Sherwin » 30 Aug 2008, 15:24

Thanks Uri,

I will try making Romi more materialistic to see what happens.

Fixed depth testing with Romi will always be deceptive as I have the following two ideas in the search:

1) in the root search the first move is searched full depth. Then only moves that zero the 50 move counter are searched full depth.

2) in the regular search when depth == 1 it returns beta if the eval >= beta
User avatar
Michael Sherwin
 
Posts: 168
Joined: 21 Jul 2005, 06:10
Location: USA


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 41 guests