PST of Fruit 2.1 and Rybka 1.0 Beta

[mballicora]

I attach two programs that respectively compute the PST of Fruit 2.1 and Rybka 1.0 Beta.

I finally had to time to compile your 2 utilities. Perhaps you can explain some major differences.

The answer is quite simple. One table is from Fruit, the other is from Rybka.

May I say, that I find this kind of post by Ed to be very annoying. He ignores the actual point being made, makes a specious insinuation and repeats the pattern until the opponent gives up and he can declare victory.

Ed, you know damn well that the numbers in the two PSTs are not simply a linear combination of each other, and nobody has claimed that. What Mark is saying is that one piece of code (taken from Fruit 2.1) with minimal modifications, can produce Rybka 1.0 Beta's entire PSTs.

What it was modified according to Zach code was changing all the multipliers while keeping the ramp vectors. That is not minimal. That is about changing half of the independent numbers.

This is not simply a coincidence, and so far no one has found it to be the case with any other chess program (and Bob at least, has looked a bit for one).

Bob has looked for nothing, and if he did, he was not seeing. He could not even found it in his own engine and when he tried to show stockfish tables as a proof they were different, they were a match to Fruit!

I did not do any of the following:

(1) look for a single PST that matched. I was looking at ALL.

(2) I did not try to subtract different values that were added in, to see if I could get down to something that does match Fruit. I claim that makes ZERO sense. Of course you can remove all values and everybody matches perfectly with 0 values everywhere. You claim stockfish matched. I claim it didn't, adding piece values changes several parts of a program, not just the PST table. Etc...

Oh, give me a break. Stockfish does not count because it adds the piece values in the PST? Adding the piece value in the PST or after does not change a single thing. You keep talking about semantics and you come with this?

Miguel

So if you believe I "looked for nothing" feel free to believe what you want. I looked for what I said I looked for, I didn't find it.

I mentioned Glaurung and I was completely ignored more than once. He said he was going to use a calculator to confirm what I showed, and never replied. Later, I found that in this forum, and rybka forum (twice), was again claiming that no one came with an example, when he previously ignored me.

Now he is claiming below that most of the engines code their PSTs manually. Not true! I showed 3 examples of similar vector mechanics.
http://rybkaforum.net/cgi-bin/rybkaforu ... 362954;hl=
And there are more. Xpdnt, initializes their PSTs automatically, and based on the regularity I see in many others, I bet that they do it too. This automatization is cleary not rare in the open source community.

"he claimed most". I showed 3. I am sure that "3" is a major part of "most" right?

Occam's Razor dictates that the most plausible explanation for this is that Vas copied the PST along with the rest of Fruit 2.1's eval. If you think this is not true, its up to you to provide a better alternate theory. So far, nothing I've read about the PSTs from you or Miguel comes even close to explaining away the 'coincidence'.

Coincidence is not the point. The issue is that I believe you cannot claim that copying simple ramp vectors is wrong.
Once you study a source code (as VR claimed), adopting those vectors (which include basic chess knowledge) is really trivial. The rest of the multipliers are different and even 4 tables are plain different.

Miguel

[mballicora]

If there were no evidence other than the PSTs, I agree it would be too weak to mean much of anything. Fortunately, that's not the case. The PST evidence is part of a pattern of behaviour of Vas. He copied code from Crafty, then when Fruit 2.1 was out he went through it backwards and forwards and "took many things". Including the PST schema and more or less the entire eval.

Whether or not Rybka's PST can be calculated using some different-looking code based on some standard ramp vectors is pretty much irrelevant, because its pretty obvious that that's not what happened.

No, you can generate them with a different looking code WITHOUT using any ramp vector AT ALL. That is what I showed, pointing to the fact that the vectors contain basic chess knowledge (centralization, punish edges) that could be dissected and expressed in other ways.

Miguel

Yes, but again, the most likely explanation for the Rybka 1.0 PST values being what they are is NOT that Vas reverse-engineered the basic chess knowledge and wrote his own original code whose linear combinations of vectors just happened to be structurally identical to the ones expressed in Fruit. Sorry, but that is too far-fetched when taken together with the other copied eval features.

Again, that is not the point. He could have RE the knowledge, I did, I and I would have done it that way, why not him? still, the issue is not that.

Even if the true information content of the PSTs is not very high, there is still some room for originality there. But Vas didn't design an original PST framework using basic chess knowledge or ideas gleaned from Fruit. Instead, he just copied the one from Fruit 2.1 and changed some numbers in it.

Did not change "some numbers", he changed all of them (assuming Zach's code). He kept the ramps. Now, copying the framework is not copying code, but adapting the idea.

Whether this copying of the PST schema, by itself, would be enough to make the program non-original or not (in the Rule 2 sense) is a difficult question and I think your efforts have helped to argue that the answer should be "no". Fortunately, the panel did not have to consider that question, because there was lots of other evidence of derivation to help us decide that Rybka 1.0 Beta through Rybka 2.3.2a were not original.

If we ever do have an accusation against an engine and a compatible PST schema is the only evidence of non-originality that can be found, then my guess is that it would not be enough to decide that the program violated Rule 2. Unless every table entry was copied verbatim or something (and maybe not even then? Fortunately such a grey-area case has not come up yet).

Yes, I mentioned Glaurung and Gull (and there are more, like Critter <=> Robbolito, by the author's admission). I see that the whole community is in silence about this PST issue, when many people (only counting the open source!) are doing similar things with vectors. Bravo for Richard Vida who had the balls to say this upfront.

Miguel

[mballicora]

I attach two programs that respectively compute the PST of Fruit 2.1 and Rybka 1.0 Beta.

I finally had to time to compile your 2 utilities. Perhaps you can explain some major differences.

The answer is quite simple. One table is from Fruit, the other is from Rybka.

May I say, that I find this kind of post by Ed to be very annoying. He ignores the actual point being made, makes a specious insinuation and repeats the pattern until the opponent gives up and he can declare victory.

Ed, you know damn well that the numbers in the two PSTs are not simply a linear combination of each other, and nobody has claimed that. What Mark is saying is that one piece of code (taken from Fruit 2.1) with minimal modifications, can produce Rybka 1.0 Beta's entire PSTs.

What it was modified according to Zach code was changing all the multipliers while keeping the ramp vectors. That is not minimal. That is about changing half of the independent numbers.

This is not simply a coincidence, and so far no one has found it to be the case with any other chess program (and Bob at least, has looked a bit for one).

Bob has looked for nothing, and if he did, he was not seeing. He could not even found it in his own engine and when he tried to show stockfish tables as a proof they were different, they were a match to Fruit!

I did not do any of the following:

(1) look for a single PST that matched. I was looking at ALL.

(2) I did not try to subtract different values that were added in, to see if I could get down to something that does match Fruit. I claim that makes ZERO sense. Of course you can remove all values and everybody matches perfectly with 0 values everywhere. You claim stockfish matched. I claim it didn't, adding piece values changes several parts of a program, not just the PST table. Etc...

So if you believe I "looked for nothing" feel free to believe what you want. I looked for what I said I looked for, I didn't find it.

I mentioned Glaurung and I was completely ignored more than once. He said he was going to use a calculator to confirm what I showed, and never replied. Later, I found that in this forum, and rybka forum (twice), was again claiming that no one came with an example, when he previously ignored me.

Now he is claiming below that most of the engines code their PSTs manually. Not true! I showed 3 examples of similar vector mechanics.
http://rybkaforum.net/cgi-bin/rybkaforu ... 362954;hl=
And there are more. Xpdnt, initializes their PSTs automatically, and based on the regularity I see in many others, I bet that they do it too. This automatization is cleary not rare in the open source community.

"he claimed most". I showed 3. I am sure that "3" is a major part of "most" right?

Yes, funny. I mentioned 3 but of course there are plenty besides those. Protector, Daydreamer, Bobcat, Jabba, Stockfish, among the ones a I checked are or look automatized. Many others do not have PSTs. I do not know what your definition of most is, but manually coded PSTs are not an overwhelming majority.

Miguel

Occam's Razor dictates that the most plausible explanation for this is that Vas copied the PST along with the rest of Fruit 2.1's eval. If you think this is not true, its up to you to provide a better alternate theory. So far, nothing I've read about the PSTs from you or Miguel comes even close to explaining away the 'coincidence'.

Coincidence is not the point. The issue is that I believe you cannot claim that copying simple ramp vectors is wrong.
Once you study a source code (as VR claimed), adopting those vectors (which include basic chess knowledge) is really trivial. The rest of the multipliers are different and even 4 tables are plain different.

Miguel

[BB+]

5th tabel,
Fruit -8 -8
Rybka -504 -588
How can -504 and -588 represent -8 at the same time ?

Fifth table is opening bishops? Referring to the templates in RYBKA_FRUIT (5.2.3, Table 7, page 8), the first "-8" is -6x+y, while the second is -4x, in both cases with (x,y)=(2,4). The Rybka 1.0 Beta reconstruction from Fruit 2.1 code uses (x,y)=(147,378).

Same table, second row,
Fruit -8 0
Rybka -588 84
How can 0 in Fruit be 84 in Rybka ?

The "0" in Fruit is -2x+y, which computes to zero with (x,y)=(2,4) as above. Similarly, this is computed to be 84 with the (x,y) choice in the Rybka reconstruction.

Case-3. The weirdest of all. The red in Rybka should produce far higher numbers. For instance not -755 but -1134 to follow a copy pattern.

This is about the back rank penalty (the z variable in the template). This number is -10 in Fruit, and -251 in the Rybka reconstruction from Fruit 2.1 code. Similar to the above, the result is the linear combination -6x+y-z, which is -18 in Fruit 2.1 and -755 in Rybka.

[Rebel]

Ahh, now I get it!

You aren't claiming he didn't copy the PST from Fruit. You're just claiming that it wasn't wrong. If he hadn't copied lots of other stuff too, you would claim the result was still his original work.

...hmm.

You are out of the scope with the issue at hand. The issue is PST alone. Is Miguel right or wrong, that's the question. Answer this first, then we move to the next subject of the report. Which might be a subject of your choice. But first the PST issue.

[Rebel]

Please explain case-1. how can -8 -8 (Fruit) change into -504 and -588 (rybka)? It should have been either -504/-504 or -588/-588. Correct?

Case-2. How can 0 change into 84? 0 multiplied with any number still remains 0.

Case-3. The weirdest of all. The red in Rybka should produce far higher numbers. For instance not -755 but -1134 to follow a copy pattern.

You should read Marc Watkins' document. All this is adequately explained.

If there were really such glaring inconsistencies in the evidence don't you think the ICGA panel would have noticed?

It has been admitted the panel hardly looked into the PST issue. I don't say that with the intend to blame the panel. Just as a fact. I understand the complexity of the issue and that issues were skipped (or shortly discussed) for time reasons. Nevertheless it was hardly discussed. Fact.

[hyatt]

Where was that admitted? We discussed it quite a bit...

More mind-reading?

[Rebel]

Whether this copying of the PST schema, by itself, would be enough to make the program non-original or not (in the Rule 2 sense) is a difficult question and I think your efforts have helped to argue that the answer should be "no".

Thank you.

Then it would not be a real problem to modify the Zach and BB documents accordingly.

But I understand you are not Zach nor BB.

[Rebel]

If we ever do have an accusation against an engine and a compatible PST schema is the only evidence of non-originality that can be found, then my guess is that it would not be enough to decide that the program violated Rule 2. Unless every table entry was copied verbatim or something (and maybe not even then? Fortunately such a grey-area case has not come up yet).

Yep.

One thing I give you nevertheless, the idiotic large Rybka numbers are obviously a sign these are not hand-typed but generated. A chess programmer wants to have his PST's surveyable for easy reading, check the harmony between the other PST tables and squares within a PST table. All for easy tuning reasons. Instead, the Rybka numbers are a pain for the human mind.

[hyatt]

Not if one uses Fruit's simple code and just tweaks those multipliers and tests until optimal results are obtained...