Question for Zach

[Chris Whittington]

Zach,

on the topic of the PST ....

in your work on construction of the PSTs, we can note from the source code, whether the left hand Fruit column or the right hand Rybka column, that the positional scores developed from the 1D ramping arrays and the weights are additive into the PST matrices.

Q1 what was in the matrices beforehand? Initialised to zero in rybka and fruit cases, or was there something there already?

Q2 Mark Lefler wrote, I forget exactly what, but the gist seemed to be something about balancing the PST tables for pawn value. I may be being random about this, but is anything done to the tables AFTER the ramping/weights code you show?

Thanks in advance

Chris W

[hyatt]

Initialized to zero. If you look at the fruit source, in pst.cpp, you see this:

for (piece = 0; piece < 12; piece++) {
for (sq = 0; sq < 64; sq++) {
for (stage = 0; stage < StageNb; stage++) {
P(piece,sq,stage) = 0;
}
}
}

So it makes sure everything is zero. I'd prefer to make 'em global and let 'em default to zero myself...

[Chris Whittington]

Initialized to zero. If you look at the fruit source, in pst.cpp, you see this:

for (piece = 0; piece < 12; piece++) {
for (sq = 0; sq < 64; sq++) {
for (stage = 0; stage < StageNb; stage++) {
P(piece,sq,stage) = 0;
}
}
}

So it makes sure everything is zero. I'd prefer to make 'em global and let 'em default to zero myself...

Well, yes, I understand that, although the question was actually for Zach.

Two questions still remain, were the tables zero before Zach's PST set up code (the 1D ramp arrays and weights he showed), or was there something there already? One reason I ask is that the first instruction when meeting the matrix cell for the first time is += rather than =

Second question still remains, was anything done to the matrices AFTER Zach's shown code.

Thanks for your help.

Chris W

[hyatt]

Yes (they were zeroed to start with) and No (after his code has initialized them, nothing else was done). As I have already shown, Zach's code produces _exactly_ the PST values that Fruit produces. I dumped em after initialization in Fruit and posted those to confirm this. Fruit zeros the values before that first +=. I did the same with Zach's code when I ran it, by simply making the PST array global rather than local, which guarantees it is set to zero (too lazy to type a loop to zero it when I can let the compiler take care of it for me and tell the O/S "fill these pages with zeros when they are paged in rather than leaving garbage laying around."

His final values from the code in his report match 1-1 with Fruit. And when you change the 4 multipliers, the same happens for Rybka's values...

I have _not_ checked the pawn values recently, however. But I would expect them to match. I started with knights, as I mentioned. We can go on to bishops (which match also) if you want.

BTW Zach can obviously answer for himself. But here I knew the answer because I had already run his code and even posted what I ran over on the Rybka forum so that anybody could try it (his code is incomplete, no "int main()", plus a pair of missing macros to extract the rank/file from a square number, plus the code to actually print the values out.).

[mjlef]

Zach,

on the topic of the PST ....

in your work on construction of the PSTs, we can note from the source code, whether the left hand Fruit column or the right hand Rybka column, that the positional scores developed from the 1D ramping arrays and the weights are additive into the PST matrices.

Q1 what was in the matrices beforehand? Initialised to zero in rybka and fruit cases, or was there something there already?

Q2 Mark Lefler wrote, I forget exactly what, but the gist seemed to be something about balancing the PST tables for pawn value. I may be being random about this, but is anything done to the tables AFTER the ramping/weights code you show?

Thanks in advance

Chris W

Chris, I am not sure I understand Q2, which seems to be directed to me. For pawns, Fruit and Rybka 1.0 are slighlty different when they apply small bonuses to some center pawns. Here is the code for Fruit:

static const int PawnFileOpening = 5;
...
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
PawnFile[square_file(sq)] *
PawnFileOpening;
}
P(piece,D3,Opening) += 10;
P(piece,E3,Opening) += 10;
P(piece,D4,Opening) += 20;
P(piece,E4,Opening) += 20;
P(piece,D5,Opening) += 10;
P(piece,E5,Opening) += 10;

And here is Zach's pseudo code for Rybka
static const int PawnFileOpening = 181;
static const int PawnFileEndgame = -97;
...
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
PawnFile[square_file(sq)] *
PawnFileOpening;
P(piece,sq,Endgame) +=
PawnFile[square_file(sq)] *
PawnFileEndgame;
}
P(piece,D5,Opening) += 74;
P(piece,E5,Opening) += 74;

Some notes:
Fruit bonuses center pawns on ranks 3-5. Rybka only on the 5th rank. Note Rybka uses about 3200 or so for a pawn value instead of the more common 100, so divide the Rybka values by 32 to compare them. Also, Fruit uses a fixed value of 0 for pawn endgame PST, where Rybka uses a negative multiplier in the endgame.

One thing worth noting is that there was a lot of discussion of PST values by the panel. Some could argue that this is not "code" but "data". I feel the basic concepts of assigning the values were copied. But you will note in the main comparison document (http://icga.wikispaces.com/file/view/EVAL_COMP.pdf), Mark Watkins does not even mention them (well, except for some trapped in corner penalties for knight I think). So we concentrated on other evaluation features when determining evaluation feature overlap.

[Chris Whittington]

Zach,

on the topic of the PST ....

in your work on construction of the PSTs, we can note from the source code, whether the left hand Fruit column or the right hand Rybka column, that the positional scores developed from the 1D ramping arrays and the weights are additive into the PST matrices.

Q1 what was in the matrices beforehand? Initialised to zero in rybka and fruit cases, or was there something there already?

Q2 Mark Lefler wrote, I forget exactly what, but the gist seemed to be something about balancing the PST tables for pawn value. I may be being random about this, but is anything done to the tables AFTER the ramping/weights code you show?

Thanks in advance

Chris W

Chris, I am not sure I understand Q2, which seems to be directed to me. For pawns, Fruit and Rybka 1.0 are slighlty different when they apply small bonuses to some center pawns. Here is the code for Fruit:

static const int PawnFileOpening = 5;
...
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
PawnFile[square_file(sq)] *
PawnFileOpening;
}
P(piece,D3,Opening) += 10;
P(piece,E3,Opening) += 10;
P(piece,D4,Opening) += 20;
P(piece,E4,Opening) += 20;
P(piece,D5,Opening) += 10;
P(piece,E5,Opening) += 10;

And here is Zach's pseudo code for Rybka
static const int PawnFileOpening = 181;
static const int PawnFileEndgame = -97;
...
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) +=
PawnFile[square_file(sq)] *
PawnFileOpening;
P(piece,sq,Endgame) +=
PawnFile[square_file(sq)] *
PawnFileEndgame;
}
P(piece,D5,Opening) += 74;
P(piece,E5,Opening) += 74;

Some notes:
Fruit bonuses center pawns on ranks 3-5. Rybka only on the 5th rank. Note Rybka uses about 3200 or so for a pawn value instead of the more common 100, so divide the Rybka values by 32 to compare them. Also, Fruit uses a fixed value of 0 for pawn endgame PST, where Rybka uses a negative multiplier in the endgame.

One thing worth noting is that there was a lot of discussion of PST values by the panel. Some could argue that this is not "code" but "data". I feel the basic concepts of assigning the values were copied. But you will note in the main comparison document (http://icga.wikispaces.com/file/view/EVAL_COMP.pdf), Mark Watkins does not even mention them (well, except for some trapped in corner penalties for knight I think). So we concentrated on other evaluation features when determining evaluation feature overlap.

Well, I hope we can agree that of the ten tables used in Fruit/Rybka that the stats are 4 tables multiplicatively identical, 6 tables not.

I note that the replies here from the esteemed programmers are that the ONLY data in either Fruit or Rybkas PST's is as shown by Zach's PST code. I assume Rybka then accounts for the material balance within the "unique Rybka material balance table(s)", where then does Fruit do it?


Meanwhile, it beats me why concentrate the discussion on the PST table values themselves when good reading of Zach's document shows:

PST tables = [identical ramping arrays] + [different weights], where "+" is used a bit loosely of course and the resulting PST tables are visually indecipherable and appear to be a mix of patterns and chaos together. - very difficult for lays and even some programmers to make sense of.

If Zach's assumptions about the code generation are to be believed, then the critical, and much easier to see and consequently discuss, identical parts of the Fruit/Rybka comparison is simply these ramping tables. Hyatt has been invited to discuss them on the free Rybka forum, but has so far declined.

[hyatt]

I've not declined anything...

BTW can you explain what you mean by 4 are, 6 are not?

Let's pick "one that is not" and see what happens. Knights look perfect. So where next do we go???

[Sean Evans]

Initialized to zero. {{Balance deleted}}

Ummm....is your name Zach?

[lmader]

Ummm....is yours?

Last I checked, this was a discussion forum, not a personal email acount. I'm pretty sure people chip in where they can. In fact, that is pretty much the definition, dare I say the spirit, of a discussion forum.