PST of Fruit 2.1 and Rybka 1.0 Beta

Code, algorithms, languages, construction...
Chan Rasjid
Posts: 33
Joined: Thu Jun 10, 2010 4:41 pm
Real Name: Chan Rasjid

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by Chan Rasjid » Thu Aug 25, 2011 7:16 pm

I also consider it a challenge to find a 2005-era engine (on any engine which is not specifically Fruit-influenced) whose PST can be replicated via a set of modifications that is comparable to the smallness of the Rybka/Fruit difference.
Only Rybka alone would produce the PST values to be that close to Fruit.

ICGA probably could set their own standard to judge similiarity and apply Rule#2. But the broader issue many would like to address also is with copyrights laws. If Vasik interpreted based on copyrights and took a stance that it is ok, he was not dishonest as he was made out to be - plagarism.

Can we be certain that "this amount of closeness" is a certainty that, in litigation, Vasik would lose - say through a "learned, unbaised and best" analysis. Could not Vasik argue based on triviality - that he could reproduced his "knowledge of the PST" easily at any time.

When does learning stops and copying begins. Is this ever an issue in copyrights cases?

Rasjid.

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by hyatt » Thu Aug 25, 2011 8:20 pm

BB+ wrote:
Chris Whittington wrote:The trick is to be adversarial some of the time (which usually involves a full on dismissal of the opposition case and a full-on assertion of one's own) [...]
This was not the working methodology of the Panel, nor particularly one that I find all that valuable. Maybe, as you say, I think too "academically/scientifically", but I think it has many advantages. For instance, the above confrontational model has frequently led to personal innuendo (in some cases quite shameless), which (to me at least) has been a major case of "irritation" that was absent in the Panel.
Chris Whittington wrote:By being non-adversarial for a couple of minutes, I was investigating with you to determine if the actual PST positions were actually as far apart as they perhaps seemed. Your reply is a bit too woffly to determine though. My guess is you would probably like to compromise but are worried about the loss of face that might ensue.
I could propose the opposite -- once I posted this direct challenge from the data, you "almost immediately" tried to bump the discussion to a meta-level... :roll: As I say, I don't think such debating techniques are efficacious. Nor is guessing about my possible fear of humiliation if/when I am shown to be wrong.

The above challenge stands. As an example, I will investigate the (current) Stockfish numbers, which have been noted elsewhere to have at least some Fruit congruence, and see how easy it is to reproduce said numbers (and do so exactly, not just approximately) with the Fruit 2.1 code. Again I don't want to pre-bias the discussion by naming a metric of "code changes" (e.g., if one can match 5 pieces with one change each, but kings are radically different and take 30 changes, is that worse than 15 changes evenly distributed? -- is changing a "ramping array element" the same as changing a "tuning parameter"?), but will report want I find, at least if this topic hasn't diverged to nonsense by the time I complete said task.

Here's a really "vague" description of a problem. Suppose the base PST "formula" for one PST is just +16 on the four center squares, +12 one square away, +8 2 squares away, and +4 on the edge. Suppose program A (say Fruit) uses just that as his PST values.

Program 2, an old Crafty or Cray Blitz uses those SAME values to initialize the board. It then biases the numbers to center the values around 0, roughly. So it uses 4 values of -6 -2 +2 and +6 rather than the 4, 8, 12, 16 in fruit. Then it adds in the value of the specific piece (say minor = 325) to every square. And then it does some root preprocessing and adds some values on top of that that try to attract pieces toward the enemy king. Say +10 for the squares adjacent to the current enemy king's position, +4 for squares one farther away, and +2 for squares one further (and that's it).

Now, do we call those "similar"? I would have to say "no". The original PST only contained a "distance from center" penalty, nothing more. The new PST adds the value of the particular piece (which can vary depending on endgame or middlegame phase, and it then adds more values to attract friendly pieces toward the enemy king.

One argument I am seeing from the "PSTs are very simple crowd" is that it is ok to take the above values, and say "OK, first we factor out that king tropism stuff, then we factor out the piece value stuff, then we normalize all the scores so that they start at 4, and we have fruit... IE what can we do to get from B to Fruit? And once they find enough, they say "OK, fruit is simple, this program is simple, they look the same. They ALL look the same. I claim that first, -6, -2, 2, 6 will play differently than 4, 8, 12, 16. I have already tested this. One can drop quite a few elo just mucking around with these values because it doesn't take much to over-value or under-value a piece with such changes.

SO. How to compare. If one piece of a PST initialization is the same, I say "what about the rest"? If they only have one piece of information in each, then yes, they are the same. If they are biased by some constant, then they are close, but not exact. If you superimpose other information like piece values, distance to opponent king, distance to passed pawns, value of squares that can't be attacked by pawns, then even though at a very elemental level they have something in common, they end up having more that is different and that would make them "not cousins."

The Rybka case is quite different. Here, the SAME code will produce either Rybka or Fruit values if you just change the individual term multiplies to correct for the approximate difference in material score differences. Yes, there are a couple of extra, or even missing (depending on your POV) bonuses for specific center squares, But if 60 are the same, or 62 or the same, and two squares were tweaked, that's still the same values...

User avatar
Rebel
Posts: 515
Joined: Wed Jun 09, 2010 7:45 pm
Real Name: Ed Schroder

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by Rebel » Sun Aug 28, 2011 2:40 pm

BB+ wrote: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.

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

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

Same table, first row verus last row,

Fruit
-8 -8 -6 -4 -4 -6 -8 -8
-18 -18 -16 -14 -14 -16 -18 -18

Rybka
-504 -588 -441 -294 -294 -441 -588 -504
-755 -839 -692 -545 -545 -692 -839 -755

How does Fruit -8 and -18 (factor 2.25) correlate with Rybka -504 and -755 (factor 1.5) ?

For clarity I attach the 2 PST output files
Attachments
rybka.txt
Rybka PST output file
(4.62 KiB) Downloaded 208 times
fruit.txt
Fruit PST output file
(4.62 KiB) Downloaded 204 times

wgarvin
Posts: 47
Joined: Thu Jul 01, 2010 3:51 pm
Real Name: Wylie Garvin

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by wgarvin » Sun Aug 28, 2011 3:45 pm

Rebel wrote:
BB+ wrote: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. 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).

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

wgarvin
Posts: 47
Joined: Thu Jul 01, 2010 3:51 pm
Real Name: Wylie Garvin

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by wgarvin » Sun Aug 28, 2011 4:07 pm

If you were not actually insinuating anything there, but just asking an honest question... then I apologize. I think I am starting to get annoyed with this whole sideshow, and might stop following the threads.

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by hyatt » Sun Aug 28, 2011 4:14 pm

I believe that Mark said he had also looked at several different programs, and has even found a couple that appear to be fruit clones that were not advertised as such.

I really believe that MOST pst values are hand-coded. Mine were until I started to cluster test and needed a way to "alter" the values dynamically so that I could fiddle with the increments, the origin (centering the scores on zero) and such. That being the case, the fruit PST initialization is not going to fit unless the PSTs are automatically generated as in Fruit. And even when they are automatically produced, there are lots of options from adding in piece values, kingside attraction, center of pawn mass attraction, to even key squares in a particular opening (very early versions of Crafty would notice that we are in a QP-type opening, and discourage Nc3/Nc6 until the corresponding C pawn had moved. There are lots of options for information that can be superimposed onto a PST.

However, there is a trend in these discussions. If someone can come up with an argument that can not be disproved, regardless of how unlikely it is (say space aliens gave him those PST values) then the case is closed, because we obviously can never prove that space aliens didn't help him. That's sort of where we are today. Out into those real "fringe/x-files/twilight-zone" explanations...

However, I do have a new angle worth looking at. Yesterday I ran one of my "pattern checks" on Rybka 1.5 (not 1.6.1 which triggers everything wildly). Didn't see anything "interesting". Since it was rated significantly lower than Crafty, and in fact one rating list had it at exactly the same rating as fruit 1.0, that makes me wonder.

Did he copy fruit 1.0, then move to Crafty since it was way stronger (over +400 at the time) and then move back to fruit when it passed Crafty.

Investigating...

User avatar
Rebel
Posts: 515
Joined: Wed Jun 09, 2010 7:45 pm
Real Name: Ed Schroder

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by Rebel » Sun Aug 28, 2011 5:43 pm

wgarvin wrote:If you were not actually insinuating anything there, but just asking an honest question... then I apologize.
Accepted.

Of course it's not linear. Factors 3200 and 3399 do matter.

I wrote the post with that in mind.

PST's when copied are sync in nature.

And especially in the last example there is no sync at all.

So I ask for an explanation.

wgarvin
Posts: 47
Joined: Thu Jul 01, 2010 3:51 pm
Real Name: Wylie Garvin

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by wgarvin » Sun Aug 28, 2011 5:58 pm

Ah, OK. Its pretty obvious but I'll spell it out anyway.

Vas copied Fruit's PST-generating code, not a table of numbers. He copied the code, changed a bunch of constants, ran the code and put the resulting table of numbers into his engine. Simple.

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by hyatt » Sun Aug 28, 2011 8:11 pm

wgarvin wrote:Ah, OK. Its pretty obvious but I'll spell it out anyway.

Vas copied Fruit's PST-generating code, not a table of numbers. He copied the code, changed a bunch of constants, ran the code and put the resulting table of numbers into his engine. Simple.

And since a table can be filled in in multiple passes, the individual constants/factors get added. Making the final sum not comparable in the traditional sense. However, I posted the comparisons after each pass of the initialization code a month back or so to show exactly this effect...

And then there is PERFECT correlation until you get to something like an extra bonus just on e5/d5 or something that really is different...

User avatar
Rebel
Posts: 515
Joined: Wed Jun 09, 2010 7:45 pm
Real Name: Ed Schroder

Re: PST of Fruit 2.1 and Rybka 1.0 Beta

Post by Rebel » Sun Aug 28, 2011 8:18 pm

wgarvin wrote:Ah, OK. Its pretty obvious but I'll spell it out anyway.

Vas copied Fruit's PST-generating code, not a table of numbers. He copied the code, changed a bunch of constants, ran the code and put the resulting table of numbers into his engine. Simple.
I get all that :)

Fruit left. Rybka right.
 -8  -8  -6  -4  -4  -6  -8  -8        -504 -588 -441 -294 -294 -441 -588 -504
 -8   0  -2   0   0  -2   0  -8        -588   84 -147    0    0 -147   84 -588
 -6  -2   4   2   2   4  -2  -6        -441 -147  378  147  147  378 -147 -441 
 -4   0   2   8   8   2   0  -4        -294    0  147  672  672  147    0 -294
 -4   0   2   8   8   2   0  -4        -294    0  147  672  672  147    0 -294
 -6  -2   4   2   2   4  -2  -6        -441 -147  378  147  147  378 -147 -441 
 -8   0  -2   0   0  -2   0  -8         588   84 -147    0    0 -147   84 -588
-18 -18 -16 -14 -14 -16 -18 -18        -755 -839 -692  545 -545 -692 -839 -755
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.

Post Reply