Page 1 of 1
piece-square tables/pseudo-mobility
Posted:
14 Aug 2008, 10:02
by Roman Hartmann
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
Re: piece-square tables/pseudo-mobility
Posted:
14 Aug 2008, 11:03
by Richard Allbert
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
Re: piece-square tables/pseudo-mobility
Posted:
14 Aug 2008, 11:13
by Roman Hartmann
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
Re: piece-square tables/pseudo-mobility
Posted:
15 Aug 2008, 21:31
by Richard Allbert
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.
over 300 games.
I'm wondering if less could be more here....
Richard
Re: piece-square tables/pseudo-mobility
Posted:
16 Aug 2008, 04:16
by Michael Sherwin
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.
Re: piece-square tables/pseudo-mobility
Posted:
19 Aug 2008, 14:43
by Michael Sherwin
Okay, someone make a post as I hate seeing my name for days at a time, every time I visit.
Re: piece-square tables/pseudo-mobility
Posted:
19 Aug 2008, 16:36
by Brian Richardson
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
Re: piece-square tables/pseudo-mobility
Posted:
20 Aug 2008, 22:12
by Roman Hartmann
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
Re: piece-square tables/pseudo-mobility
Posted:
20 Aug 2008, 22:22
by Roman Hartmann
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
Re: piece-square tables/pseudo-mobility
Posted:
22 Aug 2008, 18:12
by Daniel Shawul
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
Re: piece-square tables/pseudo-mobility
Posted:
23 Aug 2008, 03:36
by Michael Sherwin
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.
Re: piece-square tables/pseudo-mobility
Posted:
28 Aug 2008, 20:42
by YvesLejeail
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
Yves
Re: piece-square tables/pseudo-mobility
Posted:
29 Aug 2008, 07:48
by Uri Blass
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
Re: piece-square tables/pseudo-mobility
Posted:
30 Aug 2008, 04:11
by Michael Sherwin
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?
Re: piece-square tables/pseudo-mobility
Posted:
30 Aug 2008, 11:21
by Uri Blass
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
Re: piece-square tables/pseudo-mobility
Posted:
30 Aug 2008, 11:59
by Uri Blass
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
Re: piece-square tables/pseudo-mobility
Posted:
30 Aug 2008, 15:24
by Michael Sherwin
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