ChessBase: A Gross Miscarriage of Justice in Computer Chess

[Jeremy Bernstein]

And I am waiting for an admission from Zach and Mark since August / September when the issue was debunked by Chris and Miguel

I refer you (again -- or is it re-re-re-again?) to my challenge to reproduce any other engine's PST with as few code changes from Fruit 2.1. http://www.open-chess.org/viewtopic.php?f=5&t=1570

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.

This is VERY disappointing coming from you.

From your latest piece of work:

4.4.1 PST tables
As noted above, the PST tables in Rybka 1.0 Beta can be reproduced exactly via an abnormally small variation from the code in Fruit 2.1.

I compiled your OWN code and its results is listed on : http://www.top-5000.nl/pst.htm

And the PST's are NOWHERE exact, not in the widest vista.

The Rykba 1.0 Beta PST tables are generated by that code. That is, they are reproduced exactly. I tend to think that you are having a language comprehension issue, Ed.

Jeremy

[hyatt]

Crossposting from Talkchess:

Actually the issue is EXACTLY as it is presented in Zach's paper. Apparently your math skills have disappeared over the years, because anyone with some basic understanding of the concepts of "associative, commutative and distributive" properties as they apply (or don't apply) to addition vs multiplication.

Everybody can check for themselves if I did my work correctly on the false PST issue. Download the 2 C-programs offered by Mark Watkins, compile and run them and compare, they match my page exactly. It's double checked by another programmer.

The Zach Wegner / Mark Watkins Fruit and Rybka PST code can be downloaded at : http://www.open-chess.org/viewtopic.php?f=5&t=1570

I would actually be pleased if someone can confirm my findings.

Hint, after compilation run it with the > extension, it will create a textfile instead of printing things on the screen.

So:

Code: Select all

PST_FRUIT >fruit.txt
PST_RYBKA >rybka.txt

It's much more confortable.

I don't normally post here for well-known reasons, but your claim is, for reasons only known to you, thoroughly ingenuous and needs to be debunked here and now.

The PST evidence demonstrates that Vas used the Fruit PST-generation code to generate his PSTs by changing a couple of values, NOT that the Rybka PSTs are a 1 to 1 copy of the Fruit PSTs, scaled to Rybka's pawn values (which is what your website shows). The two C source files demonstrate this quite clearly.

Code: Select all

-> diff PST_FRUIT.c PST_RYBKA.c 
52,55c52,56
< static const int PawnFileOpening = 5;
< static const int KnightCentreOpening = 5;
< static const int KnightCentreEndgame = 5;
< static const int KnightRankOpening = 5;
---
> static const int PawnFileOpening = 181;
> static const int PawnFileEndgame = -97; // added line
> static const int KnightCentreOpening = 347;
> static const int KnightCentreEndgame = 56;
> static const int KnightRankOpening = 358;
57,68c58,69
< static const int KnightTrapped = 100;
< static const int BishopCentreOpening = 2;
< static const int BishopCentreEndgame = 3;
< static const int BishopBackRankOpening = 10;
< static const int BishopDiagonalOpening = 4;
< static const int RookFileOpening = 3;
< static const int QueenCentreOpening = 0;
< static const int QueenCentreEndgame = 4;
< static const int QueenBackRankOpening = 5;
< static const int KingCentreEndgame = 12;
< static const int KingFileOpening = 10;
< static const int KingRankOpening = 10;
---
> static const int KnightTrapped = 3200;
> static const int BishopCentreOpening = 147;
> static const int BishopCentreEndgame = 49;
> static const int BishopBackRankOpening = 251;
> static const int BishopDiagonalOpening = 378;
> static const int RookFileOpening = 104;
> static const int QueenCentreOpening = 98;
> static const int QueenCentreEndgame = 108;
> static const int QueenBackRankOpening = 201;
> static const int KingCentreEndgame = 401;
> static const int KingFileOpening = 469;
> static const int KingRankOpening = 0; // most numbers above changed
90,93c91,95
<  {P(piece,sq,Opening) += PawnFile[square_file(sq)] * PawnFileOpening;}
<  P(piece,D3,Opening) += 10; P(piece,E3,Opening) += 10;  // centre control
<  P(piece,D4,Opening) += 20; P(piece,E4,Opening) += 20;
<  P(piece,D5,Opening) += 10; P(piece,E5,Opening) += 10;
---
>  {P(piece,sq,Opening) += PawnFile[square_file(sq)] * PawnFileOpening;
>   P(piece,sq,Endgame) += PawnFile[square_file(sq)] * PawnFileEndgame;} // added
>  // P(piece,D3,Opening) += 10; P(piece,E3,Opening) += 10;  // centre control
>  // P(piece,D4,Opening) += 20; P(piece,E4,Opening) += 20; // two lines removed
>  P(piece,D5,Opening) += 74; P(piece,E5,Opening) += 74; // change numbers

Ed KNOWS that. This is just a blatant attempt at trying to make a point by resorting to dishonesty when there is no factual evidence to support his point of view...

[hyatt]

And I am waiting for an admission from Zach and Mark since August / September when the issue was debunked by Chris and Miguel

I refer you (again -- or is it re-re-re-again?) to my challenge to reproduce any other engine's PST with as few code changes from Fruit 2.1. http://www.open-chess.org/viewtopic.php?f=5&t=1570

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.

This is VERY disappointing coming from you.

From your latest piece of work:

4.4.1 PST tables
As noted above, the PST tables in Rybka 1.0 Beta can be reproduced exactly via an abnormally small variation from the code in Fruit 2.1.

I compiled your OWN code and its results is listed on : http://www.top-5000.nl/pst.htm

And the PST's are NOWHERE exact, not in the widest vista.

Can you not read and comprehend?

If you take the fruit PST code, make the changes Zach provided, and run this, the output will match Rybka's PST values EXACTLY. You are acting like an idiot by trying to alter his statement to say "the rybka and fruit pst values match exactly." That is NOT what his statement says, nor does the ICGA report make that statement. And I do not believe for a minute that you are that idiotic. Therefore, dishonesty is the only possible remaining explanation...

[hyatt]

The Rykba 1.0 Beta PST tables are generated by that code. That is, they are reproduced exactly. I tend to think that you are having a language comprehension issue, Ed.

Jeremy

He is not having a comprehension issue, he is having an honesty issue...

Nobody interprets that statement to mean what he is claiming. NOBODY.

[BB+]

[Riis] then gives some quotations from Letouzey, erroneously claimed to be from 2008 (the interview is from 2005, note that "Fruit 2.0" is the latest version therein).

Upon looking at differences between evaluation in Fruit 2.0 and Fruit 2.1 (such as KingAttack, open files for rooks, pawn storms...), I would say that this chronological error of Riis is sufficiently damaging to make his quotation from the Quisinsky interview be out of context.

[mwyoung]

Now I remember why this place was created and named Open Chess. Because current news topics can be posted here without being thrown into engine origins to hide the topics from public view...

Nice to have a place to go to read both sides of this topic...

Thanks Open Chess.

[Rebel]

If you take the fruit PST code, make the changes Zach provided, and run this, the output will match Rybka's PST values EXACTLY. You are acting like an idiot by trying to alter his statement to say "the rybka and fruit pst values match exactly." That is NOT what his statement says, nor does the ICGA report make that statement. And I do not believe for a minute that you are that idiotic. Therefore, dishonesty is the only possible remaining explanation...

It's what you have done all the time.

Just 2 quotes.

As I have said _many_ times. One PST match could be luck. And one is all there is in Crafty. While in Rybka they _all_ match.

Actual PST values are code. Copying them would not be acceptable.

Silly man.

But lemme answer Jeremy, someone I consider an honest person.

[Rebel]

The Rykba 1.0 Beta PST tables are generated by that code. That is, they are reproduced exactly. I tend to think that you are having a language comprehension issue, Ed.

No

But you are close now, ready for part II, my page is 100% correct, I quote:

With the above values (and now things become technical) the Rybka investigators Zach Wegner and Mark Watkins in order to find traces of copying after all tried Fruit's PST initialization code, tried various parameter settings, found some matches and claimed copying.

VIG at work. Vas is a copy boy. He copied Fruit, period. Now we must find evidence he copied the PST's. But we have a problem, the PST's don't match at all. Someone got an idea, let's try the Fruit initialization code and see how far we come. So following Mark words they changed Fruit's formula a bit, played around with the Fruit parameters and claimed copying, found some matches (not all match) and claimed copying confirm the VIG tunnel vision. A working mechanism if you think VIG and already are convinced Vas copied Fruit. No doubts here.

Then Chris sets the PST's on the agenda (at that time i was still VIG myself), Miguel moves in and demonstrates with DIFFERENT code the SAME can be accomplished. It worked as another eye-opener for me.

However as professor Miguel Ballicora clearly demonstrated with his OWN utilities the same can be accomplished with total different code so the basic premise using Fruit's formula to proof Rybka values is wrong, there are infinite possible formula to accomplish that.

Let's recap this case from a scientific point of view and count the ASSUMPTIONS that are made:

The facts first:

1. Fruit does not have PST data, PST's are created by initialization code at program start.
2. Rybka has PST data inside, there is no initialization code.
3. The PST values totally differ.

The assumptions:

1. Vas is copy-boy and an obfuscator, in order to hide the Fruit origins he obfuscated the depth, nodes, pawn value 100 -> 3200 and for advanced obfuscation added another ingredient 3200 ->3399, he changed the order in EVAL and UCI -> changed time control from float to int, removed all Fruit's UCI options (20) and replaced it with one Fruit does not have. It's all refuted on: http://www.top-5000.nl/evidence.htm There is no fixed pattern of obfuscation and yet with the PST's one has to assume there is to make the case plausible.

2. Second assumption, since there is no PST initialization code in Rybka we must ASSUME Vas copied the Fruit initialization code, made it a standalone C-utility, changed the code somewhat, played around with the parameters then imported the PST data into the Rybka sources. Obfuscation mission accomplished. Oh yes, Vas multiplied the values with 32 for maximum obfuscation, by all means let's not forget that.

3. Third assumption, Vas a no-name in computer chess till december 2005 must have realized that after the release of Fruit 2.1 5½ months earlier (June 2005) he would become so famous his program would be hacked, reverse engineered and therefore all this kind of obfuscations were absolutely needed to hide the Fruit origins and yet was stupid enough to call Strelka his own, the latter actually being evidence for his innocence. An obfuscator would keep his mouth shut. A copy-boy would hide, knowing that by claiming Strelka as his own that is oil on the fire for the accusers since Strelka is half Fruit, half Rybka. Yet we saw a strong and normal emotional reaction from a programmer who discovered his program was cloned. We have seen such strong reactions before, from Bob, from Mark Lefler when someone took his work and called it Scaramanga.

Too much assumptions to my taste and after Miguel demonstrated:

1. That other (non-Fruit) code can accomplish the same;
2. That numbers like (-3,-1,0,+1) are the base of every PST and none can claim copyright on 4 characters;
3. How little information and specific content PST's cells have;

that it's far more logical Vas created his own PST's as he stated last month himself.

Vasik Rajlich: The piece-square table C# code - unfortunately I have only the code which creates my piece-square tables today. The piece-square tables are similar but not exactly the same as the Rybka 1 piece-square tables. Also, I definitely have tinkered with the C# code in the last six years. For example now I use .NET reflection, which AFAIK was not even around in 2005. So, it won't be exact. Plus, I'll probably want to delete a few things. Is this really worth doing? It's hard for me to see this as a major issue. (December, 2011)

Vasik Rajlich: During my tuning I used ints, but much finer than pawn=3200. I needed to be able to "perturb" each eval weight minimally and calculate the delta for the fit between eval scores and game results. This is the "gradient" part of gradient descent. (December 2011)

Vas created the Rybka 1 PST's with his own written code in C# and he (in principle) is willing to show it.

So much more likely, that is of course if you think VII.

What I dislike about this whole issue (and this is not about you Jeremy) is that the main accusers Mark and Zach are not willing to give in that their PST theory is based on VIG and are not able to admit a mistake. They consistently refuse to give Miguel the credit he deserves for overlooking a couple of things Mark and Zach could not imagine at the time they wrote down the PST accusations in their documents.

[hyatt]

If you take the fruit PST code, make the changes Zach provided, and run this, the output will match Rybka's PST values EXACTLY. You are acting like an idiot by trying to alter his statement to say "the rybka and fruit pst values match exactly." That is NOT what his statement says, nor does the ICGA report make that statement. And I do not believe for a minute that you are that idiotic. Therefore, dishonesty is the only possible remaining explanation...

It's what you have done all the time.

Just 2 quotes.

As I have said _many_ times. One PST match could be luck. And one is all there is in Crafty. While in Rybka they _all_ match.

Actual PST values are code. Copying them would not be acceptable.

Silly man.

But lemme answer Jeremy, someone I consider an honest person.

All you can do is lie, it would seem? I have ALWAYS discussed this in the context of Fruit's PST code will produce Rybka's VALUES with the CONSTANT CHANGES Zach reported. I have NEVER said anything different. You want to lie, you want to distort, you want to do anything possible to make it look like the ICGA panel was incompetent. I don't even believe you are this incompetent, you are just this dishonest.

The "match" I have ALWAYS talked about is the match between the values that are tied together by the SAME initialization code. You can't produce ALL of my PSTs with fruit's code. I looked at a half-dozen or so OTHER programs and Fruit's code won't produce their PST values. Mark Watkins reported that he had looked at others. Same result. So we have exactly two programs which can have their PST values computed EXACTLY by the same piece of code using a few different constant values. You are simply dishonest in your statements, and even worse, you KNOW you are.

Your response to Jeremy is JUST as dishonest. Zach didn't change Fruit's "formula" as you say. He changed 3-4 constants per PST, the ramping is unchanged. You want to use a well-known theorem that says for any semantic formulation, there are an infinite number of syntactic expressions that will produce that semantic behavior. Well-known. But if it is so likely that Vas/Fabien somehow produced the SAME formulation through coincidental serendipitous development, why can't we find ANOTHER program that Fruit's code will work for? Won't work for mine. Won't work for any I tried. Nor Mark. Nor others. This is simply a hopeless argument. "That there exists..." does not mean "it is likely that it happened." To solve that dilemma, you are going to have to find OTHERS that can be matched, PST by PST, with Fruit's code.

There's absolutely no reason for Mark/Zach (or anyone on the panel) to change their mind about the PST code. You refuse to look at the data "in toto". You ignore the gross copying in his pre-1.0 beta versions and want to hand-wave that off as not important. You want to hand-wave off the rather amazing 4-5 months where suddenly all the crafty eval and search is gone, and the fruit search and eval is suddenly present. And you think he wrote it by himself. Right...

[Rebel]

All you can do is lie, it would seem? I have ALWAYS discussed this in the context of Fruit's PST code will produce Rybka's VALUES with the CONSTANT CHANGES Zach reported.

Blah blah blah...........

Read what you have written yourself man.

By all your manipulations you constantly contradict yourself, people remember what you said, there are people that practically save everything to hold it against you later and then you have to lie your way out of it, as in this case.