mballicora wrote:All the multipliers are changed (21, not 17 if I count correctly) and vectors are not, which I **mentioned** in my sentence. Most of them are repeated and simetrical, which means that what is kept, in terms of independent variables, is lower that what you imply.
At least someone is referring back to the original data in this discussion.
Here is the list:
Code: Select all
/* 01 */ static const int PawnFileOpening = 5; // 181
/* 01a */ static const int PawnFileEndgame; // only in Rybka
/* 02 */ static const int KnightCentreOpening = 5; // 347
/* 03 */ static const int KnightCentreEndgame = 5; // 56
/* 04 */ static const int KnightRankOpening = 5; // 358
/* 05 */ static const int KnightBackRankOpening = 0; // unchanged
/* 06 */ static const int KnightTrapped = 100; // 3200 (scaled?)
/* 07 */ static const int BishopCentreOpening = 2; // 147
/* 08 */ static const int BishopCentreEndgame = 3; // 49
/* 09 */ static const int BishopBackRankOpening = 10; // 251
/* 10 */ static const int BishopDiagonalOpening = 4; // 378
/* 11 */ static const int RookFileOpening = 3; // 104
/* 12 */ static const int QueenCentreOpening = 0; // 98
/* 13 */ static const int QueenCentreEndgame = 4; // 108
/* 14 */ static const int QueenBackRankOpening = 5; // 201
/* 15 */ static const int KingCentreEndgame = 12; // 401
/* 16 */ static const int KingFileOpening = 10; // 469
/* 17 */ static const int KingRankOpening = 10; // 0
The other changes are with central pawns, and I'm not sure whether you are calling these "multipliers", though I don't think 21 vs 17 matters much anyway. The UCI options (like
PieceActivityWeight) are not apparent in Rybka 1.0 Beta [e.g., if 250 were used there rather than 256, one would expect various fidgetry from rounding to appear in the R1 arrays, rather than the linear formulae being exact]. Given the pedantry seen in other places, I guess I should also chastise your use of the word "All" when
KnightBackRackOpening did not change, being 0 in both.
The thread has diverged a lot, but the original
challenge still stands AFAIK. And as previously, I will let others debate the relative importance of vectors, "tuning" parameters, and code changes. I personally would argue that of these three, the greatest "originality" is in the code/methodology, second would be the specific vectors, while last is the parameters (here outside influences such as strength also seem to play a greater part). I should emphasise that this is my opinion
in the Fruit 2.1 context, and for other PST schemes the case could be different (or as RV has proposed, it might just be "equally irrelevant" on the whole).
On the matter of the vectors, I agree that
-3,-1,0,1 is not different from
-2,0,1,2 in terms of chess value, but would argue that it
is different from the standpoint of likelihood of copying. On the matter of Rybka 1.0 Beta copying "something" from Fruit 2.1 (as an impetus for thinking the PST code/method was re-used also), there is the iterative search deepening and the search control (see Appendix A and the end of 6.3.2 of RYBKA_FRUIT), both of which fairly inarguably originated from Fruit 2.1 [well, at least no one has argued it yet]. I reiterate my previous comment that I think the "alternative reconstruction" would be more valuable if the Fruit 2.1
arrays were the only given data, and not the
code ["I printed out the Fruit 2.1 PST arrays and went through them forwards and backwards...
].