Winboard Forum

Hi chess programmers,

to get a little bit distanced from Perft and basic move generating efficiency it would be good to talk on the way, legal moves would be generated in a more realistic environment than in Perft.

That would mean, e.g. to investigate how the move generating would look like, when been supported by move preevaluation and sorting. Under such circumstances Smirf is showing a wide range of efficiency, depending whether working within a check threat or not and whether depending check threats would be relevant or not.

So I will show here a bandwidth of Smirf's results at some examples (8x8 and 10x8, FRC/CRC):

Code: Select all

FEN: 6R1/B7/8/7N/2P2P2/3k4/KPQ5/8 b - - 0 1

=>+-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   :::   :::<R>:::|
7 |<B>   :::   :::   :::   | Testscenario (sorted):
6 |   :::   :::   :::   :::| Move generation (check threat: 0xf0)
5 |:::   :::   :::   :::<N>|
4 |   :::<P>:::   <P>   :::| Test #:      05
3 |:::   :::[k]:::   :::   |
2 |<K><P><Q>:::   :::   :::| Move Count:  1*750000
1 |:::   :::   :::   :::   | per Second:  6000000
  +-a--b--c--d--e--f--g--h-+ Time:        0.125 sec

  8.258 Kd3xc2


FEN: 3q2R1/2P5/1k1B4/4np2/1NPK1Pr1/1R6/PP1N1Q2/3q2b1 w - - 0 1

  +-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   [q]   :::<R>:::|
7 |:::   <P>   :::   :::   | Testscenario (sorted):
6 |   [k]   <B>   :::   :::| Move generation
5 |:::   :::   [n][p]:::   |
4 |   <N><P><K>   <P>[r]:::| Test #:      00
3 |:::<R>:::   :::   :::   |
2 |<P><P>   <N>   <Q>   :::| Move Count:  37*750000
1 |:::   :::[q]:::   [b]   | per Second:  9155394
=>+-a--b--c--d--e--f--g--h-+ Time:        3.031 sec

  15.58 c7xd8Q+  11.92 c7xd8R   10.90 c7xd8B+  10.04 c7xd8N   8.321 Rg8xd8
  7.292 c7-c8Q   4.688 Rg8xg4   3.917 c7-c8R   3.232 Kd4xe5+  2.709 Qf2xg1
  2.417 c7-c8N+  2.292 c7-c8B   0.809 Nb4-d5+  0.601 Nb4-a6+  0.601 Nb4-c6+
  0.583 c4-c5+   0.560 Kd4-d5+  0.466 Kd4-c3+  0.338 Nb4-d3+  0.286 Nb4-c2+
  0.191 a2-a4    0.180 Rg8-e8   0.143 Qf2-e3   0.097 a2-a3    0.092 Rg8-f8
  0.039 Rg8-g6   0.029 Rg8-g7   0.029 Rg8-g5  -0.016 Rb3-a3  -0.016 Rb3-c3
 -0.061 Rb3-d3  -0.095 Rg8-h8  -0.126 Rb3-e3  -0.143 Kd4-e3  -0.202 Rb3-f3
 -0.286 Rb3-g3  -0.375 Rb3-h3


FEN: 8/8/8/4B2b/6nN/8/5P2/2R1K2k w Q - 0 1

  +-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   :::   :::   :::|
7 |:::   :::   :::   :::   | Testscenario (sorted):
6 |   :::   :::   :::   :::| Move generation
5 |:::   :::   <B>   :::[b]|
4 |   :::   :::   :::[n]<N>| Test #:      16
3 |:::   :::   :::   :::   |
2 |   :::   :::   <P>   :::| Move Count:  34*750000
1 |:::   <R>   <K>   :::[k]| per Second:  13949671
=>+-a--b--*--d--*--f--g--h-+ Time:        1.828 sec

  88.40 O-O-O#   87.98 Ke1-e2#  87.89 Ke1-d2#  0.404 Be5-h2   0.279 Be5-g3
  0.160 Nh4-g2   0.141 Be5-f4   0.101 Ke1-f1   0.101 Rc1-d1   0.017 Nh4-f3
  0.000 Be5-d4  -0.010 Rc1-c2  -0.039 Be5-c3  -0.039 Rc1-c3  -0.039 Be5-f6
 -0.060 f2-f3   -0.084 Rc1-c4  -0.101 Rc1-b1  -0.101 Ke1-d1  -0.109 Be5-b2
 -0.109 Be5-g7  -0.138 f2-f4   -0.142 Be5-d6  -0.142 Rc1-c5  -0.149 Nh4-f5
 -0.202 Be5-a1  -0.202 Rc1-a1  -0.202 Be5-h8  -0.209 Rc1-c6  -0.212 Nh4-g6
 -0.284 Be5-c7  -0.284 Rc1-c7  -0.364 Rc1-c8  -0.426 Be5-b8


FEN: 3k4/8/8/2N4b/6n1/8/5P2/R3K2R w KQ - 0 1

  +-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   [k]   :::   :::|
7 |:::   :::   :::   :::   | Testscenario (sorted):
6 |   :::   :::   :::   :::| Move generation
5 |:::   <N>   :::   :::[b]|
4 |   :::   :::   :::[n]:::| Test #:      02
3 |:::   :::   :::   :::   |
2 |   :::   :::   <P>   :::| Move Count:  32*750000
1 |<R>   :::   <K>   :::<R>| per Second:  14492753
=>+-*--b--c--d--*--f--g--*-+ Time:        1.656 sec

  3.372 Rh1xh5   1.007 O-O-O+   0.966 Ra1-a8+  0.594 Nc5-b7+  0.594 Nc5-e6+
  0.562 Ra1-d1+  0.479 O-O      0.450 Ra1-a7   0.405 Ra1-a6   0.341 Ra1-a5
  0.264 Ra1-a4   0.243 Rh1-h4   0.218 Nc5-d7   0.187 f2-f4    0.180 Ra1-a3
  0.168 Rh1-h3   0.108 Ke1-d2   0.100 Ke1-e2   0.095 f2-f3    0.092 Ra1-a2
  0.086 Rh1-h2   0.079 Rh1-f1   0.055 Ra1-c1   0.045 Rh1-g1   0.034 Ra1-b1
  0.007 Ke1-d1  -0.021 Ke1-f1  -0.045 Nc5-a6  -0.097 Nc5-e4  -0.186 Nc5-a4
 -0.186 Nc5-d3  -0.224 Nc5-b3


FEN: rcbbkarnqn/pppppppppp/0/0/0/0/PPPPPPPPPP/RCBBKARNQN w KQkq - 0 1

  +-*--b--c--d--*--f--*--h--i--j-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][c][b][b][k][a][r][n][q][n]|
7 |[p][p][p][p][p][p][p][p][p][p]| Testscenario (sorted):
6 |   :::   :::   :::   :::   :::| Move generation
5 |:::   :::   :::   :::   :::   |
4 |   :::   :::   :::   :::   :::| Test #:      19
3 |:::   :::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P><P><P>| Move Count:  27*750000
1 |<R><C><B><B><K><A><R><N><Q><N>| per Second:  19067796
=>+-*--b--c--d--*--f--*--h--i--j-+ Time:        1.062 sec

  0.225 Nh1-g3   0.225 Cb1-c3   0.222 Nj1-i3   0.209 Af1-e3   0.202 e2-e4
  0.198 f2-f4    0.198 d2-d4    0.187 g2-g4    0.187 c2-c4    0.173 b2-b4
  0.173 h2-h4    0.170 Af1-g3   0.157 a2-a4    0.157 i2-i4    0.142 j2-j4
  0.122 Cb1-a3   0.122 Nh1-i3   0.101 e2-e3    0.099 d2-d3    0.099 f2-f3
  0.095 c2-c3    0.095 g2-g3    0.089 b2-b3    0.089 h2-h3    0.082 a2-a3
  0.082 i2-i3    0.075 j2-j3


FEN: 8/p7/8/1P6/4B3/P6p/5K1k/8 w - - 0 1

  +-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   :::   :::   :::|
7 |[p]   :::   :::   :::   | Testscenario (sorted):
6 |   :::   :::   :::   :::| Move generation
5 |:::<P>:::   :::   :::   |
4 |   :::   :::<B>:::   :::| Test #:      04
3 |<P>   :::   :::   :::[p]|
2 |   :::   :::   <K>   [k]| Move Count:  20*750000
1 |:::   :::   :::   :::   | per Second:  24630541
=>+-a--b--c--d--e--f--g--h-+ Time:        0.609 sec

  0.263 Be4-g2   0.263 Be4-h1   0.138 Be4-f3  -0.000 Be4-f5  -0.021 a3-a4
 -0.024 Kf2-f3  -0.024 Kf2-f1  -0.051 b5-b6   -0.052 Be4-d3  -0.052 Be4-g6
 -0.101 Kf2-e2  -0.117 Kf2-e3  -0.117 Kf2-e1  -0.141 Be4-c2  -0.141 Be4-d5
 -0.141 Be4-h7  -0.250 Be4-b1  -0.283 Be4-c6  -0.425 Be4-b7  -0.567 Be4-a8


Regards, Reinhard.

If I understand correctly you show the scores that Smirf gives for order of moves.

In my case the scores of most moves are simply the history table scores
and only captures or promotions can get different scores when after captures or promotions I search killers if they are legal.


Uri

Hi Uri,

If I understand correctly you show the scores that Smirf gives for order of moves.

that is right. The examples show the movelist AFTER sorting and preevaluating, which are included in the timings mentioned. The preevaluation consists of a combination of material gain (modified to MVV/LVA behaviour), intuitive positional change values, check threat and mating bonusses.

In my case the scores of most moves are simply the history table scores and only captures or promotions can get different scores when after captures or promotions I search killers if they are legal.

The mover ordering in my case also would be overruled by detected killer moves or optimal moves. Because not within a tree evaluation I avoided to simulate such examples. I think, that this would nearly correlate to your history table, which I do not use.

What do you think on Smirf's sorting results?

Regards, Reinhard.

If I understand correctly you do not detect piece under threat in your move ordering(not that I do it but I do not claim that my move ordering is better)

In the example of this position Rh2 is better in the list than moves that do not lose material.

3k4/8/8/2N4b/6n1/8/5P2/R3K2R w KQ - 0 1

I guess that you use only some piece square table of the moves in case that the move is not check or capture.

Uri

Hi Uri,

If I understand correctly you do not detect piece under threat in your move ordering(not that I do it but I do not claim that my move ordering is better)

remember that I am not using something like attack tables. Therefore Smirf in this situation does not know anything on good or bad captures or defendings. The MVV/LVA behaviour should manage to have an effective quiescence (or more matching for Smirf: deescalating) search. Because stable material balance there is only one aspect of being "quiet" an attack table alone would not be sufficient to provide the relevant information Smirf would need. Thus also here an attack table would not be that helpful as it should be. Therefore I (yet) do not use such a table.

I guess that you use only some piece square table of the moves in case that the move is not check or capture.

Not exactly this, instead I am overlaying using ONE table in every case. This table consists of CONSTANT values, therefore it does not consume additional timing.

The sorting results of Smirf's moves generator should be seen and commented based on that fact, that nothing has been done yet concerning quiescence search at that moment.

Regards, Reinhard.

Reinhard Scharnagl wrote:Hi Uri,

If I understand correctly you do not detect piece under threat in your move ordering(not that I do it but I do not claim that my move ordering is better)

remember that I am not using something like attack tables. Therefore Smirf in this situation does not know anything on good or bad captures or defendings. The MVV/LVA behaviour should manage to have an effective quiescence (or more matching for Smirf: deescalating) search. Because stable material balance there is only one aspect of being "quiet" an attack table alone would not be sufficient to provide the relevant information Smirf would need. Thus also here an attack table would not be that helpful as it should be. Therefore I (yet) do not use such a table.

I guess that you use only some piece square table of the moves in case that the move is not check or capture.

Not exactly this, instead I am overlaying using ONE table in every case. This table consists of CONSTANT values, therefore it does not consume additional timing.

Hi Reinhard,
I think that every piece square table consists of CONSTANT values so I do not understand the difference.

Uri

Hi Uri,

I think that every piece square table consists of CONSTANT values so I do not understand the difference

piece dependant square tables (in my opinion) do not make sense here. Therefore I have ONE common CONSTANT table but differently handled depending on some piece positions. (Let me keep some things secret.) :-) Piece depending constant square tables are NONSENSE, though they may work during the opening phase of a chess game.

I see, that I have to include the starting position's ordered moves, to document that my approach will also work during the opening phase:

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]|
7 |[p][p][p][p][p][p][p][p]| Testscenario (sorted):
6 |   :::   :::   :::   :::| Move generation
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Test #:      28
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Move Count:  20*750000
1 |<R><N><B><Q><K><B><N><R>| per Second:  21337126
=>+-*--b--c--d--*--f--g--*-+ Time:        0.703 sec

  0.225 Nb1-c3   0.220 Ng1-f3   0.202 e2-e4    0.198 d2-d4    0.198 f2-f4
  0.187 c2-c4    0.187 g2-g4    0.173 h2-h4    0.173 b2-b4    0.157 a2-a4
  0.146 Ng1-h3   0.122 Nb1-a3   0.101 e2-e3    0.099 d2-d3    0.099 f2-f3
  0.095 g2-g3    0.095 c2-c3    0.089 b2-b3    0.089 h2-h3    0.082 a2-a3


Regards, Reinhard.

Hi Reinhard,

I do not use piece square table for ordering of moves but only for evaluation(when I tried to use it for order of moves I did not find piece square table to be superior to history tables).

I thought that you may use difference in piece square table values for ordering the quiet moves( you did not explain how you get the scores and it was simply a first guess).

Without knowing how you get the scores I see no way to compare order of moves between smirf and other programs.

The tables that I use have constant values like many chess programs but I do not use only the tables to decide about the evaluation.

The tables that I have are

int pcsq[5][64];
int kingtable[2][64];

I have
PAWN=0
KNIGHT=1
BISHOP=3
ROOK=4
QUEEN=5

pcsq[piece][sq] gives the value of black piece in the square sq.

kingtable[0][sq] gives the value of the king in the square sq in the opening stage.

kingtable[1][sq] gives the value of the king in the square sq in the endgame stage.

The value of the king in the middle game is some average between the value of the king in the opening and the value of the king in the opening.

Uri

Hi Uri,

well, the table, that I use has nothing to do with the later positional evaluation. It is simply a kind of change of distance from the moving piece to the enemy king with a maximum of one pawn entity.

I would avoid any positional evaluation, which depends on the phase of the game. If the detail or positional evaluation would be good, it would work in any phase, regardless whether opening, middle or endgame. To make differences here means to confess, that the evaluation function is not really understood, but has been composed from taste or believe.

I just have adjusted my preevaluation to prefer the a-side in case of nearly equal distance exchanges:

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]|
7 |[p][p][p][p][p][p][p][p]| Testscenario (sorted):
6 |   :::   :::   :::   :::| Move generation
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Test #:      28
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Move Count:  20*750000
1 |<R><N><B><Q><K><B><N><R>| per Second:  21337126
=>+-*--b--c--d--*--f--g--*-+ Time:        0.703 sec

  0.225 Nb1-c3   0.220 Ng1-f3   0.202 e2-e4    0.198 d2-d4    0.198 f2-f4
  0.187 c2-c4    0.187 g2-g4    0.173 b2-b4    0.173 h2-h4    0.157 a2-a4
  0.146 Ng1-h3   0.122 Nb1-a3   0.101 e2-e3    0.099 d2-d3    0.099 f2-f3
  0.095 c2-c3    0.095 g2-g3    0.089 b2-b3    0.089 h2-h3    0.082 a2-a3

Regards, Reinhard.

Hi Uri,

you wanted to see the table I use (the center is a zero value), but I do not know, whether it would help you:

Code: Select all

     Dump of SternInfo-Hi (Penalty-L):
x00: 0001 0001 0001 :::: :::: :::: :::: :::: :::: :::: :::: :::: 0001 0001 0001
x0F: 0001 0001 :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: 0001 0001
x1E: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
x2D: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
x3C: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
x4B: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
x5A: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
x69: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
x78: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
x87: :::: :::: :::: :::: :::: :::: :::: ---- :::: :::: :::: :::: :::: :::: ::::
x96: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
xA5: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
xB4: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
xC3: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
xD2: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
xE1: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
xF0: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: ::::
xFF: 0001 0001 :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: :::: 0001 0001
x0E: 0001 0001 0001 :::: :::: :::: :::: :::: :::: :::: :::: :::: 0001 0001 0001
     Dump of SternInfo-Lo (Penalty-L):
x00: 26D3 17B2 0A3A FEAD F551 EE68 EA29 E8BB EA29 EE68 F551 FEAD 0A3A 17B2 26D3
x0F: 12DF 0295 F3F2 E749 DCF0 D53D D07C CEE0 D07C D53D DCF0 E749 F3F2 0295 12DF
x1E: FFFB EE66 DE71 D07B C4F0 BC42 B6DB B505 B6DB BC42 C4F0 D07B DE71 EE66 FFFB
x2D: EE66 DB6A C9F6 BA79 AD78 A38D 9D4D 9B29 9D4D A38D AD78 BA79 C9F6 DB6A EE66
x3C: DE70 C9F5 B6D9 A594 96CA 8B43 83DE 814E 83DE 8B43 96CA A594 B6D9 C9F5 DE70
x4B: D078 BA77 A593 9248 814D 73A8 6AA2 6773 6AA2 73A8 814D 9248 A593 BA77 D078
x5A: C4EC AD75 96C7 814C 6DB7 5D3F 51CA 4D98 51CA 5D3F 6DB7 814C 96C7 AD75 C4EC
x69: BC3E A389 8B40 73A5 5D3D 4926 39D7 33BD 39D7 4926 5D3D 73A5 8B40 A389 BC3E
x78: B6D5 9D48 83D8 6A9D 51C6 39D4 2496 19E2 2496 39D4 51C6 6A9D 83D8 9D48 B6D5
x87: B4FE 9B23 8148 676D 4D91 33B6 19DB ---- 19DB 33B6 4D91 676D 8148 9B23 B4FE
x96: B6D3 9D46 83D6 6A9A 51C1 39CE 248C 19D5 248C 39CE 51C1 6A9A 83D6 9D46 B6D3
xA5: BC3A A385 8B3B 739F 5D36 491D 39CB 33B0 39CB 491D 5D36 739F 8B3B A385 BC3A
xB4: C4E7 AD70 96C0 8144 6DAE 5D34 51BD 4D8B 51BD 5D34 6DAE 8144 96C0 AD70 C4E7
xC3: D072 BA70 A58B 923F 8142 739C 6A95 6766 6A95 739C 8142 923F A58B BA70 D072
xD2: DE68 C9ED B6D0 A58A 96BE 8B37 83D1 8141 83D1 8B37 96BE A58A B6D0 C9ED DE68
xE1: EE5D DB60 C9EC BA6E AD6D A381 9D40 9B1C 9D40 A381 AD6D BA6E C9EC DB60 EE5D
xF0: FFF1 EE5C DE67 D06F C4E4 BC36 B6CE B4F7 B6CE BC36 C4E4 D06F DE67 EE5C FFF1
xFF: 12D5 028A F3E7 E73D DCE4 D530 D06F CED2 D06F D530 DCE4 E73D F3E7 028A 12D5
x0E: 26C8 17A7 0A2E FEA1 F544 EE5B EA1C E8AE EA1C EE5B F544 FEA1 0A2E 17A7 26C8

Regards, Reinhard.

Of course it does not help me because I understand nothing of the table.

I see that you write in base 16.
I guess that every bit has some meaning (otherwise I see no reason to write in base 16) and you get scores based on some mathematics on bits.

I understood your previous post better and what I was interested was not the exact content of your table but how you generate the scores for moves.

I still do not understand it completely but I understand the idea that it is better to get closer to the king.

Uri

Hello all,
First I would like to post the move scores for the (normal) positions posted:

Code: Select all

(zct)1. new
(zct)1. next
e4      score=120
Nc3     score=119
Nf3     score=119
d4      score=118
g3      score=114
Na3     score=114
b3      score=114
Nh3     score=114
d3      score=113
e3      score=113
a3      score=112
a4      score=110
f4      score=110
h4      score=110
f3      score=110
h3      score=110
c3      score=108
c4      score=106
g4      score=102
b4      score=102
(zct)1. setboard 6R1/B7/8/7N/2P2P2/3k4/KPQ5/8 b - -
(zct)1... next
Kxc2    score=219
(zct)1... setboard 3q2R1/2P5/1k1B4/4np2/1NPK1Pr1/1R6/PP1N1Q2/3q2b1 w - -
(zct)1. next
cxd8=Q+ score=228
cxd8=R  score=228
cxd8=B+ score=228
cxd8=N  score=228
Rxd8    score=224
Qe3     score=221
Rxg4    score=215
Rg5     score=215
Rg7     score=215
Re8     score=215
Rf8     score=215
Rh8     score=215
Kxe5+   score=213
Qxg1    score=211
Nd5+    score=113
a3      score=112
Nd3+    score=112
Rc3     score=110
Re3     score=110
Rg3     score=110
Rh3     score=110
Rg6     score=110
a4      score=110
Kc3+    score=110
Ke3     score=110
Kd5+    score=110
Ra3     score=110
c5+     score=33
c8=N+   score=29
Rf3     score=29
c8=Q    score=29
c8=R    score=29
Rd3     score=29
c8=B    score=29
Nc6+    score=28
Nc2+    score=26
Na6+    score=23
(zct)1. setboard 3k4/8/8/2N4b/6n1/8/5P2/R3K2R w KQ -
(zct)1. next
Rxh5    score=213
0-0     score=130
0-0-0   score=130
Ne4     score=111
Nd3     score=110
Ne6+    score=110
Rb1     score=110
Rc1     score=110
Rd1+    score=110
Ra2     score=110
Ra3     score=110
Ra4     score=110
Ra5     score=110
Ra6     score=110
Ra7     score=110
Ra8+    score=110
Rf1     score=110
Rg1     score=110
Rh3     score=110
Rh4     score=110
f3      score=110
f4      score=110
Nb3     score=107
Nb7+    score=106
Na4     score=105
Na6     score=104
Kd1     score=90
Kf1     score=90
Kd2     score=90
Ke2     score=90
Rh2     score=29
Nd7     score=25
(zct)1. setboard 8/p7/8/1P6/4B3/P6p/5K1k/8 w - -
(zct)1. next
Ke1     score=130
Bd5     score=110
Kf1     score=110
Ke2     score=110
Bf3     score=109
Bc6     score=109
a4      score=108
Bf5     score=107
Bb7     score=107
Bd3     score=107
Bg6     score=105
Ba8     score=105
Bc2     score=105
Bh7     score=103
Bb1     score=103
Ke3     score=90
Kf3     score=90
b6      score=29
Bg2     score=25
Bh1     score=22

Reinhard Scharnagl wrote:I would avoid any positional evaluation, which depends on the phase of the game. If the detail or positional evaluation would be good, it would work in any phase, regardless whether opening, middle or endgame. To make differences here means to confess, that the evaluation function is not really understood, but has been composed from taste or believe.

I would have to disagree. One, I say that the evaluation function is not understood at all, because it is just a bunch of meaningless terms put together by the programmer. Two, I would not say that the phase makes a difference in the "understanding" of the position. Some chess rules can be more easily stated in terms of the phase, and if the engine "understands" what phase the game is in, then it can apply the same rule.

Regards,
Zach

Hi Uri, hi Zach!

To Uri: the the table consists of two parts, the hi-part and the lo-part, which have to be seen combined as a long integer, where the hi-part is representing the integer and the lo-part the fraction of the distance to the center. the distance is normed to about 1.00 at the sides. In the edges the value will become slightly greater than 1, thus the marked edges of the hi-part. The conclusion is that not each bit is relevant but merely the complete value (mostly simply consisting of an integer fraction).

The values will be gathered by centering the table to the enemys king's position and taking the values representing the moved piece's position. The difference of those values could be taken to estimate the change of the preevaluation. And your conclusion holds, that the goal is to bonus any approaches towards the enemy king and to malus each growing distance to that king.

To Zach: I think that you are using piece and square depending predefined tables to add and subtract some "positional" values to the move to be sorted. This seems to be a quite common approach.

It seems as if you felt personally attacked by my statement on such tables. But I only am attacking the use of such an approach. Positional weights never depend only on one piece (as far as I see that problem), but always at least on two pieces from different colors are involved.

The fact, that this approach may have usable results is no proof to be the right method. Especially the most to be seen exchange of such tables depending on the (not to decide without doubt) phases of the game is itself a big indicator of that procedure to be a weak heuristic.

That critic position to such approaches even is valid for the average piece values, which has been taken more by luck than by reason. See for that at my web page: http://www.chessbox.de/Compu/schachansatz1_e.html (about 10 pages and more).

Regards, Reinhard.

Hi again Zach,

are the values you have posted a kind of board evaluation or (like in Smirf) a move ordering preevaluation? Smirf creates values, that might represent the amount of changing (more precise: increasing) the board's situation. In other words those values represent the measure of need of further investigation (to be done in a deescalation search).

Regards, Reinhard.

Hi Reinhard,

I still do not understand the table.

The board has 64 squares and the table seems to have 15*19=285 numbers.

Uri

Hi again Reinhard,

1)I tend to agree that piece square table is not good for order of moves but for different reasons.

good order of moves does not mean searching better moves first but means searching moves with bigger probability to fail high.

If you are not searching first move in the list then
It is better to search earlier a move that probably lose a piece but has 1% chances to be a good sacrifice and not to search first a quiet bad positional move that probably does not lose material but has no chances to be best.

The question what is good for order of moves and what is good for evaluation are different questions.


2)I do not claim that piece square table is the best idea to use but I cannot say that it is nonsense because it is better than nothing.

I started with piece square table and later added more information to the evaluation so of course not only piece square table is used.

It is possible that it is better to throw the piece square table if you have other information.
I also have more than one piece square table for the king based on the stage of the game but I have only one piece square table for other pieces.

Uri

Hi again Uri,

The board has 64 squares and the table seems to have 15*19=285 numbers

the table has to cover all possible distances even of an 10x8 board, an its diagonal size is reaching from the table's center into each corner. But without publishing very any detail the idea should be clear (so I hope).

I tend to agree that piece square table is not good for order of moves but for different reasons.

Because I have no attack tables (because of several reasons) I need an ordering of moves during the deescalating search. As you might have seen, my preevaluation values could be raised very cheaply (it would be interesting to know about Zach's timings). But during the final tree search I do not need any move ordering (in the usual sense). Instead I will use a kind of filter. That is because my search is for making a final DECISION, not to make a final EVALUATION. I do not know which engine could benefit by knowing the best move's exact evaluation, to know it is BEST should be sufficient.

Regards, Reinhard.

Hi again Reinhard,

I think that comparison between timing is interesting when the same information is calculated.
If a person calculates different scores for order of moves then there is a problem to compare.

It may be interesting to do some competition in calculating more information but the information should be the same.
I think for example that the move generator may include more information except number of checks and number of mates.

Information may be about pawn structure or about blocked pawns.
Information can be about material value of moves based on search that allow only captures after the moves and the material value of moves is well defined if we agree about value of pieces.
Information may be about threats against enemy pieces or about moves that threat mate in 1.


Information may be about everything that can be used by chess programs for evaluation or for pruning or for extensions or for order of moves but first we need to define exactly what information we want.

Uri

Hi again Uri,

I think that comparison between timing is interesting when the same information is calculated.
If a person calculates different scores for order of moves then there is a problem to compare.

if you are targeting on my interest to know Zach's timing, that has not been to compare only the timings, but to compare different quiescence evaluating approaches. His numbers looked like he has integrated a lot information of piece exchanges, may be taken from a sort of attack table. I wanted to know, at which costs those information has been produced. The moves sorted by Smirf's generator and the moves ordered by Zach's pre- (?) evaluation have a very different quality. Zach's values nearly look like as if he would already have made a sort of quiescence search.

But as you suggested, it might be interesting to compare results after a quiescence search (if there would not been a detail evaluation included). The problem is, that I am not completly finished with Smirf. I have worked a lot on creating a 10x8 and 8x8 aware GUI during the last time, because there has been none yet, and its about to be completed by Smirf's engine. Moreover I am convinced that Smirf would not give the usual evaluations to all the moves but simply would try to identify the best move. As I may have mentioned, the method would be somehow comparable to a Shannon B approach.

Regards, Reinhard.

Hello Reinhard and Uri,

On piece-square tables: No, I wasn't offended I just disagree. Yes, they are theoretically weak, but I mainly use them to not advance flank pawns, centralize knights, and things of that nature. They are good in that this information is usually true throughout the game, they are already scaled to a small range (this is why I can't use history easily), and they are directly linked to the evaluation function.
On my scores: Yes, these are the 8-bit presort scores used to order moves in the real search, but there is usually other information available in search(killer moves, counter moves, threat moves, hash moves). After I wrote a function to test the timings, I realized a weak spot in my code. Because I generate have to generate attack tables, my functions are a lot slower than yours (this is assuming that you are doing a full gen and prescore):

Code: Select all

(zct)1. perfs 1000000 
20000000 moves 6.304 s 3.172m mps
(zct)1. setboard 6R1/B7/8/7N/2P2P2/3k4/KPQ5/8 b - -
(zct)1... perfs 1000000
1000000 moves 2.114 s 0.473m mps
(zct)1... setboard 3q2R1/2P5/1k1B4/4np2/1NPK1Pr1/1R6/PP1N1Q2/3q2b1 w - -
(zct)1. perfs 1000000
37000000 moves 9.923 s 3.728m mps
(zct)1. setboard 3k4/8/8/2N4b/6n1/8/5P2/R3K2R w KQ -
(zct)1. perfs 1000000
32000000 moves 7.087 s 4.515m mps
(zct)1. setboard 8/p7/8/1P6/4B3/P6p/5K1k/8 w - -
(zct)1. perfs 1000000
20000000 moves 4.641 s 4.309m mps

This was on a 1.25 GHz machine, as before. So I am several times slower here, but I am generating different information. I guess this is where I need to optimize.

Regards,
Zach