PST of Fruit 2.1 and Rybka 1.0 Beta

[hyatt]

"can be recreated in other ways."

As opposed to the simpler explanation:

"since he copied lots of other code, it is quite likely that he copied the PST initialization code and used that to create his PST values by just altering the constants to reflect material differences."

Which seems more reasonable? The latter. Why did he copy the eval, and then not copy the PSTs which are an integral part? That is completely illogical and is far less likely than copying.

Most see this. I suspect you do too, but just want to argue the point for reasons unknown...

I mean, it wouldn't exactly be the FIRST time he copied someone's code would it? So why is some half-assed way-out-there explanation more likely, according to you, than the obvious explanation that is staring you right between the eyes???

[mballicora]

"can be recreated in other ways."

As opposed to the simpler explanation:

I am stating a fact, not an explanation, to someone that came late.

Miguel

"since he copied lots of other code, it is quite likely that he copied the PST initialization code and used that to create his PST values by just altering the constants to reflect material differences."

Which seems more reasonable? The latter. Why did he copy the eval, and then not copy the PSTs which are an integral part? That is completely illogical and is far less likely than copying.

Most see this. I suspect you do too, but just want to argue the point for reasons unknown...

I mean, it wouldn't exactly be the FIRST time he copied someone's code would it? So why is some half-assed way-out-there explanation more likely, according to you, than the obvious explanation that is staring you right between the eyes???

[BB+]

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... ].

[wgarvin]

I guess I will elaborate on/clarify my views from earlier in this thread (page 2 I guess). My opinion has not changed, but Since we're nitpicking fine details, I might as well detail what I think happened.

This is what I have believed, since seeing the evidence in the panel a few months ago. Note, I don't know exactly what happened, obviously; Vas did not share source code or any other info about it that might have made it clearer. So we can only speculate. But based on the other evidence, I think the most likely explanation for how Rybka 1.0's PST got the way it is, goes like this...

(1) First, I think Vas copied the PST initialization code into a small separate program. He multiplied all of the weights by a scale factor, and wrote enough code in this standalone program to dump out an initialized PST array as C code. He then ran this generator program and stuck the output in Rybka. Before Rybka 1.0 was released, he did some tuning of the weights (of the PST, and the eval generally). After changing the PST weights, he just re-ran the generator program and replaced the PST in the Rybka source with the new array.

I know from experience that a little generator program like that can be written in 10 minutes if you already have the code for generating the table handy.

I can think of a few other possibilities too:
(2) he initially copied the code to generate the table into Rybka, and only moved it to a separate program later after it was tuned.
(3) he used Rybka itself as the 'table generator' program, with an ifdef.
Or (4) he looked at the PST init code from Fruit and came up with a macro-based description of each table which allowed him to tweak weights directly in the Rybka source code, and have the compiler convert it into the initialized PST data.

I should stress that I believe (1) is the most likely, but I think all of these are 'derivation' or 'copying'. (4) is the closest to 'independent reimplementation of idea(s) from Fruit' and would be the hardest to make a case if copyright violation out of. But I also think its the least likely, because it would be the most work out of these choices. I think he probably did (1)... Its what I would have done in his place.

Now before I get pounced on: If the PST evidence was the only evidence of copying from Fruit, it might be unfair to proclaim the program as un-original just from the PST evidence. Its like circumstantial evidence in a criminal case: not enough to convict by itself, but when taken together with a bunch of other evidence, it is consistent with the pattern of copying useful bits from Fruit. It shows that Vas saved time by copying working eval infrastructure from Fruit, and spent his time tuning it to make it better. It gave him a definite advantage over competitors who wrote their own evals. Taken together, the evidence shows that he was willing to copy other people's work into Rybka in order to get ahead, and that the program is at least partly 'derived from' Fruit, and not completely 'original work' of Vas. And that's against the ICGA tournament rules.