Questions to positional detail evaluation

[Reinhard Scharnagl]

Hi all,

Smirf starts with its positional detail evaluation. I estimate the initial postion around 1/3 pawn unit for white. Thus the advantage to be allowed to make a move should be estimated to about 1/6 PU in average.

What do you regard following values to be - good or bad?

Code: Select all

FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

  +-*--b--c--d--*--f--g--*-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][n][b][q][k][b][n][r]| (Compilation: Nov  5 2004)
7 |[p][p][p][p][p][p][p][p]| Testscenario QSearch(-max, +max):
6 |   :::   :::   :::   :::| TT Accesses 26960, Success 0.0%
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Smirf Test No.: 29
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Evaluated Trees Count:  20*1348
1 |<R><N><B><Q><K><B><N><R>| TT Accesses per Second: 107840
=>+-*--b--c--d--*--f--g--*-+ Time:                   0.250 sec

  0.164 e2-e4    0.164 e2-e3    0.160 Nb1-c3   0.156 d2-d4    0.148 Ng1-f3
  0.133 d2-d3    0.020 c2-c4    0.020 c2-c3    0.000 f2-f4    0.000 f2-f3
 -0.031 h2-h4   -0.031 a2-a4   -0.035 Ng1-h3  -0.055 b2-b4   -0.055 g2-g4
 -0.055 g2-g3   -0.055 b2-b3   -0.066 Nb1-a3  -0.066 h2-h3   -0.066 a2-a3

Regards, Reinhard.

[Reinhard Scharnagl]

Hi all,

Smirf positional detail evaluation has been extended to add information on covered or attacked pieces. Thus it seems to evaluate more defensivly now:

Code: Select all

FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

  +-*--b--c--d--*--f--g--*-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][n][b][q][k][b][n][r]| (Compilation: Nov  5 2004)
7 |[p][p][p][p][p][p][p][p]| Testscenario QSearch(-max, +max):
6 |   :::   :::   :::   :::| TT Accesses 26960, Success 0.0%
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Smirf Test No.: 29
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Evaluated Trees Count:  20*1348
1 |<R><N><B><Q><K><B><N><R>| TT Accesses per Second: 107840
=>+-*--b--c--d--*--f--g--*-+ Time:                   0.250 sec

  0.188 Nb1-c3   0.184 Ng1-f3   0.180 e2-e3    0.164 d2-d3    0.160 e2-e4
  0.137 d2-d4    0.109 c2-c3    0.105 f2-f3    0.090 c2-c4    0.082 Ng1-h3
  0.082 f2-f4    0.074 Nb1-a3   0.063 h2-h3    0.063 a2-a3    0.051 g2-g3
  0.051 b2-b3    0.047 h2-h4    0.047 a2-a4    0.031 b2-b4    0.031 g2-g4

Regards, Reinhard.

[Dan Honeycutt]

I estimate the initial postion around 1/3 pawn unit for white.

Which is equivalent to saying the advantage of having the move (in the opening position) is 1/3 pawn. In Bruja, I throw in a small plus for the side moving since I figure it must be worth something. But there is no intelligence in what I do. Does anyone have a better way of evaluating the worth of having the move?

Dan H.

[Reinhard Scharnagl]

Hi Dan,

...Which is equivalent to saying the advantage of having the move (in the opening position) is 1/3 pawn...

things are more complicated. If you regard the Situation after move 1 of Black nearly equal and you would like to have comparable evaluations, you must subtract 1/6 from the positions value from the view of the one which hase moved. This the evaluation after a good first move of white has to be about 1/6 and after blacks good answer it still has to be about 1/6.

The real problem ist, that the advantage to have the right to move is not fixed but changes dynamically during the game. Because of the fact that I want to complete a first Smirf version until Monday, I do not implement a solution for that dynamic problem but instead still subtract 1/6 pawn units, knowing that this is only a weak solution.

Reinhard.

P.S.: my actual evaluation (no deep search) after some corrections is now:

Code: Select all

FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

  +-*--b--c--d--*--f--g--*-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][n][b][q][k][b][n][r]| (Compilation: Nov  5 2004)
7 |[p][p][p][p][p][p][p][p]| Testscenario QSearch(-max, +max):
6 |   :::   :::   :::   :::| TT Accesses 26960, Success 0.0%
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Smirf Test No.: 29
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Evaluated Trees Count:  20*1348
1 |<R><N><B><Q><K><B><N><R>| TT Accesses per Second: 101353
=>+-*--b--c--d--*--f--g--*-+ Time:                   0.266 sec

  0.176 e2-e3    0.148 d2-d3    0.133 Nb1-c3   0.125 Ng1-f3   0.082 e2-e4
  0.063 c2-c3    0.047 d2-d4    0.047 f2-f3   -0.027 c2-c4   -0.027 g2-g3
 -0.027 b2-b3   -0.031 Ng1-h3  -0.039 h2-h3   -0.039 a2-a3   -0.043 f2-f4
 -0.047 Nb1-a3  -0.098 h2-h4   -0.098 a2-a4   -0.121 b2-b4   -0.121 g2-g4

[Uri Blass]

In movei I have no bonus for the side to move.

The problem is that the program does not evaluate random positions in the leaves.

It is important to be correct mainly at leaf positions.

If the side to move has a good capture the position is not going to be a leaf position and positions when the side to move is in trouble tend more to be leaf positions so I doubt if bonus for the side to move is going to help(I even did not try it).

Uri

[Reinhard Scharnagl]

Hi Uri,

I do not think that the problem could be handled that way. It seems to me only an argument to "ignore" it (sometimes not the worst problem solution). But this decision highly depends on your detail evaluation end the handling of passed pawns. My detail evaluation is self constructing: that is, there are no bonus or malus tables etc.. Thus the positional detail part of the evaluation easyly could be larger than 1 pawn unit. I do not know whether other programmers would limit that part to at least one pawn unit? The result for Smirf is, that it could not simply ignore the detail evaluation and the right to move advantage.

Overmore: how many complex evaluations (in Smirf equivalent to TT accesses) does your program calculate a second in average?

Reinhard.

[Laurens Winkelhagen]

Hi all,

I found it an interesting idea to give the side to move a small bonus (I choose .2 pawn). I'm trying it right now in a series of games between the adjusted engine janwillem 1.10beta and the original engine 1.09. No other differences.

Of course, because the time control is only 1 minute for 40 moves I can't very well draw valid conclusions yet, but... the 8-2 result I got definately encourages me to test it more exhaustingly;-)

Regards, Laurens.

[Dan Honeycutt]

Hi Dan,

...Which is equivalent to saying the advantage of having the move (in the opening position) is 1/3 pawn...

things are more complicated. If you regard the Situation after move 1 of Black nearly equal and you would like to have comparable evaluations, you must subtract 1/6 from the positions value from the view of the one which hase moved. This the evaluation after a good first move of white has to be about 1/6 and after blacks good answer it still has to be about 1/6.

Hi Reinhard:

I don't follow the 1/6. If white starts with 1/3 the only thing he has is the move since the position is dead equal. If white plays a "correct" move, the score should not change. Thus whites move should net about 2/3 pawn worth of development, center control etc. Black now has the move (worth 1/3) white has the better position/development (worth 2/3) and the balance remains.

Dan H.

[Uri Blass]

Hi Uri,

I do not think that the problem could be handled that way. It seems to me only an argument to "ignore" it (sometimes not the worst problem solution). But this decision highly depends on your detail evaluation end the handling of passed pawns. My detail evaluation is self constructing: that is, there are no bonus or malus tables etc.. Thus the positional detail part of the evaluation easyly could be larger than 1 pawn unit. I do not know whether other programmers would limit that part to at least one pawn unit? The result for Smirf is, that it could not simply ignore the detail evaluation and the right to move advantage.

Overmore: how many complex evaluations (in Smirf equivalent to TT accesses) does your program calculate a second in average?

Reinhard.

Hi reinhard,

I agree that bonus for the side to move may be productive but I guess that simply giving it without conditions is not a good idea.

In extreme cases I can easily get positional bonus of more than 1 point thanks to mobility or thanks to passed pawns or thanks to king safety
and it is not a bonus that is result of my piece square table.

I have no one value for the pieces but 64 values for every piece(practically it is 32 because the evaluation is symmetric).

For the king I have 128 values because I have seperate value for the opening and for the endgame when the value is some average of these values in the middle game(I decide about the phase of the game based on the value of the pieces(no pawns) of the opponent).

When I talk here about positional evaluation of more than one pawn I talk about evaluation that is not based on these tables.

here are my tables that I do not consider as positional evaluation in this post:

pawn_square_table 990 1000 1000 1000 1000 1000 1000 990 140 140 140 140 140 140 140 140 125 125 125 125 125 125 125 125 110 110 110 115 115 110 110 110 100 102 105 110 110 105 102 100 100 101 102 95 95 102 101 100 101 100 100 80 80 100 100 101 0 0 0 0 0 0 0 0knight_square_table 210 300 340 340 340 340 300 210 300 340 350 350 350 350 340 300 330 350 355 355 355 355 350 330 330 350 355 360 360 355 350 330 330 350 355 360 360 355 350 330 340 350 355 355 355 355 350 340 320 340 350 350 350 350 340 320 220 320 340 340 340 340 320 220 bishop_square_table 350 350 350 350 350 350 350 350 300 360 360 360 360 360 360 300 360 360 365 365 365 365 360 360 350 360 365 370 370 365 360 350 350 360 365 370 370 365 360 350 350 360 360 360 360 360 360 350 350 360 360 360 360 360 360 350 340 340 340 350 350 340 340 340 rook_square_table 530 530 530 530 530 530 530 530 540 540 540 540 540 540 540 540 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 530 540 540 540 540 530 530 queen_square_table 990 1000 1000 1000 1000 1000 1000 990 990 1000 1000 1000 1000 1000 1000 990 1010 1000 1000 1000 1000 1000 1000 1010 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 990 1000 1000 1000 1000 1000 1000 990 990 1000 1000 1000 1000 1000 1000 990 king_table -60 -60 -60 -60 -60 -60 -60 -60 -50 -50 -50 -50 -50 -50 -50 -50 -45 -45 -45 -45 -45 -45 -45 -45 -40 -40 -40 -40 -40 -40 -40 -40 -35 -35 -35 -35 -35 -35 -35 -35 -30 -30 -30 -30 -30 -30 -30 -30 -10 -10 -20 -20 -20 -20 -10 -10 30 20 0 0 0 0 20 30 -24 -12 0 4 4 0 -12 -24 -12 8 20 24 24 20 8 -12 0 20 32 36 36 32 20 0 4 24 36 40 40 36 24 4 4 24 36 40 40 36 24 4 0 20 32 36 36 32 20 0 -12 8 20 24 24 20 8 -12 -24 -12 0 4 4 0 -12 -24

[Reinhard Scharnagl]

Hi Uri,

your tables seem to be constructed also to support passed pawns somehow. But I agree, that such tables are not a really positionally working instrument, because the values depend only on position and positioned piece. But I think that a lot of chess programmers would do it your way.

Smirf follows a different approach. No tables, no bonus, no malus. Still I do not know whether it would be successfull, but I derived one routine which uniquly handles piece influences by theoretical derived average exchange values and the cooperation of all pieces at each square. Thus I can apply the same routine to 10x8 boards using the capablanca piece set with no change at all. I am very intersted in its results...

Reinhard.

[Reinhard Scharnagl]

Hi Dan,

when I read the texts again, it seems to me that we only differ in the evaluation of the first move. I estimate its value to about 1/3 pawn units without correction and to 1/6 PU with correction. You seem to point on an evaluation giving about the double value.

Reinhard.

[Dan Honeycutt]

... (I choose .2 pawn)...

Hi Laurens:

The advantage of the move is greater if there are things happening. But with a chess program, you rely on the qsearch to get you to a "quiet" position where, I'd think, the advantage of the move is pretty small. Thus, your 0.2 seems a bit high. I use 0.06 and I wouldn't dispute that Uri's 0.0 may be better yet. I've never tried to test it because I imagine the improvement, if any, would be small and it would take a lot of games. But good luck with your tests and let us know what you find.

Dan H.

[Uri Blass]

Hi Reinhard,

You are right.

Originally I had no evaluation for passed pawns and I added it later.

It is possible that a good idea may be to get a bigger bonus for passed pawns and reduce the values in my tables for advanced pawns.

Uri

[Dan Honeycutt]

Hi Dan,

when I read the texts again, it seems to me that we only differ in the evaluation of the first move. I estimate its value to about 1/3 pawn units without correction and to 1/6 PU with correction. You seem to point on an evaluation giving about the double value.

Reinhard.

Hi Reinhard:

It could just as well be 1/6 for having the move and 1/3 for the positional improvement for a correct move, but I would then say that white's initial advantage is 1/6 rather than 1/3.

Dan H.

[Uri Blass]

Hi again Reinhard.

one suggestion that I have is to test everything and do not assume as obvious that bonus for the side to move is productive.

If the version with the bonus beat previous version you can keep that version.

A common mistake of programmers is that they assume things with no testing.

Uri

[Reinhard Scharnagl]

Hi Uri,

A common mistake of programmers is that they assume things with no testing.

well, may be, but I think this is in a later phase. I am more convinced that it is a bad idea to create a chess program without a clear own development idea. And to work with the right-to-move advantage was part of that concept from the very beginning.

I think you can optimize a program by testing, but you cannot make a good new approach without working with very abstract plans. Nevertheless the result could be disappointing. But what if it would be ok?

Reinhard.

[José Carlos]

Hi Uri,

A common mistake of programmers is that they assume things with no testing.

well, may be, but I think this is in a later phase. I am more convinced that it is a bad idea to create a chess program without a clear own development idea. And to work with the right-to-move advantage was part of that concept from the very beginning.

I think you can optimize a program by testing, but you cannot make a good new approach without working with very abstract plans. Nevertheless the result could be disappointing. But what if it would be ok?

Reinhard.

I tried the bonus for side to move idea some time ago. Studing the search tree, I saw it was counter productive in qsearch, for it helped to stand pat in not so good positions. Then I tried the opposite idea "if I'm fine I should have a good move", and tried reducing the eval for side to move by a small value. It made the tree grow without improvement. Finally, I removed it everywhere, except in pawn ending eval, where side to move is critical for pawn races, but the implementation there is very particular, not just a constant bonus.
On the other hand, side to move advantage can be better applied to search, rather than to eval. In search, except for zugzwang positions, which are very rare, you know that moving is better or equal than not doing anything (the null move observation), and this idea has many applications apart from the well known null-move heuristic.

[Reinhard Scharnagl]

Hi Jos?,

the bonus idea is only a weak solution for that problem. You have spoken from zugzwang situations. Well they are extrem, but obviously the advantage to have the right to move is not to be estimated by a constant value. But this is a necessary first step before implementing a more adaequate solution in Smirf, which has to become finished in its first version.

I try to avoid the nullmove heuristic. Not that it might be bad or not successful, but I think, it is still not fully understood, what makes it work. One idea for its understanding is, that NOT having an equivalent for the right-to-move has to be compensated somehow by a double move and checking what will be. Thus that working heuristic might be an unnecessary implication of not subtracting that advantage, which overmore leads to more complex search strategies. I will try without, but thus having to solve the basic problem, where I am still not that successfull it might need to be.

Reinhard.

[fierz]

Hi Dan,

SNIP

P.S.: my actual evaluation (no deep search) after some corrections is now:

Code: Select all

FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

  +-*--b--c--d--*--f--g--*-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][n][b][q][k][b][n][r]| (Compilation: Nov  5 2004)
7 |[p][p][p][p][p][p][p][p]| Testscenario QSearch(-max, +max):
6 |   :::   :::   :::   :::| TT Accesses 26960, Success 0.0%
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Smirf Test No.: 29
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Evaluated Trees Count:  20*1348
1 |<R><N><B><Q><K><B><N><R>| TT Accesses per Second: 101353
=>+-*--b--c--d--*--f--g--*-+ Time:                   0.266 sec

  0.176 e2-e3    0.148 d2-d3    0.133 Nb1-c3   0.125 Ng1-f3   0.082 e2-e4
  0.063 c2-c3    0.047 d2-d4    0.047 f2-f3   -0.027 c2-c4   -0.027 g2-g3
 -0.027 b2-b3   -0.031 Ng1-h3  -0.039 h2-h3   -0.039 a2-a3   -0.043 f2-f4
 -0.047 Nb1-a3  -0.098 h2-h4   -0.098 a2-a4   -0.121 b2-b4   -0.121 g2-g4

hi reinhard,

i can't understand how you can post these scores without further comment. they are quite clearly absurd! if your program believes that 1.d3 or 1.e3 are much stronger than 1.e4 or 1.d4 then something is wrong. and if it believes 1.f3? to be stronger than 1.c4 then something is very wrong.

cheers
martin

[Reinhard Scharnagl]

Hi Fierz,

indeed those values seem to be absurd. Thus I am wondering, that it needed so long until a comment like yours would come.

I am testing a local evaluation function WITHOUT any chess knowledge integrated by the programmer. It is not the result after a deep positonal search, only after a QSearch. If you would be able to write an evaluation function giving a correct sequence without any search, you would be the king of all programmers.

The test is mainly to estimate the evaluation speed.

Reinhard.

P.S.: moreover, my actual values are:

Code: Select all

FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1

  +-*--b--c--d--*--f--g--*-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][n][b][q][k][b][n][r]| (Compilation: Nov  8 2004)
7 |[p][p][p][p][p][p][p][p]| Testscenario QSearch(-max, +max):
6 |   :::   :::   :::   :::| (With TT Caching 384.0 MB / 4-fold)
5 |:::   :::   :::   :::   | TT Accesses 26960, Success 0.0%
4 |   :::   :::   :::   :::|
3 |:::   :::   :::   :::   | Smirf Test No.:         29
2 |<P><P><P><P><P><P><P><P>| Evaluated Trees Count:  20*1348
1 |<R><N><B><Q><K><B><N><R>| TT Accesses per Second: 107840
=>+-*--b--c--d--*--f--g--*-+ Time:                   0.250 sec

  0.164 e2-e4    0.164 e2-e3    0.148 d2-d4    0.125 Ng1-f3   0.121 d2-d3
  0.117 Nb1-c3  -0.039 c2-c4   -0.039 c2-c3   -0.066 f2-f4   -0.066 f2-f3
 -0.117 h2-h4   -0.117 a2-a4   -0.117 Nb1-a3  -0.145 Ng1-h3  -0.148 b2-b4
 -0.148 g2-g4   -0.148 g2-g3   -0.148 b2-b3   -0.164 h2-h3   -0.164 a2-a3