PST of Fruit 2.1 and Rybka 1.0 Beta

[Michel Van den Bergh]

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?

[hyatt]

You DO realize that vas changed the multiplier constants? And that the constants are summed. If you look at Mark's paper, he presented a sort of spread sheet to show what had to be multiplied/added for each value, rather than Zach's modified fruit constants that do the same thing.

For a mathematical hint a + b can be zero where X*A + Y*B might not be, depending on the values of X and Y chosen. To see this easier, take the code to print the things out and comment everything but the first initialization loop out for each, then print the numbers. Exact matches except for a constant multiplier for each and every value. Then comment out the first loop and uncomment the second. re-run. Match again except for a single constant multiplier. It's the multiplying and adding that makes them look different, when they really are not...

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

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

[wgarvin]

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.

[wgarvin]

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.

[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

[mballicora]

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.

No, I am claiming that if he "copied" information was a fraction of it and "copying" that particular fraction was not wrong.
If he "copied" the mechanics (adding two vectors to obtaing a matrix) that fall under what I would call "an idea" of how to build a PST, not the PST itself.

This all started with blatant exaggerations from BH like "PSTs are indentical", "he copied 10 of 10" etc. etc. making it look like this was a blatant cut and paste.

Miguel

[wgarvin]

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

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

[hyatt]

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?

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

[hyatt]

That is THE point. If he copied other code, and clearly he did, then why would he suddenly develop completely new code trying to target the Fruit PST arrays conceptually? Makes no sense. It is too "out there" to believe it realistic. Regardless of all this ridiculous "might have dones" and "could have dones"... The PST data simply shows a continuation of previous behavior. Who in their right mind would copy someone's eval, and then create their own PST values, when the two are so tightly coupled?

Just doesn't pass the "is this a plausible explanation" at all.

This sounds like one of those mathematician jokes. Guy announces in the hospital lobby "I have a new baby". Someone asks, "is it a boy or girl?" "Yes" he answers. Someone asks "is he nuts? or just a wise-ass?" Someone else answers, "neither, he is a mathematician."