ChessBase: A Gross Miscarriage of Justice in Computer Chess

General discussion about computer chess...
Post Reply
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: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by hyatt » Wed Jan 04, 2012 5:54 pm

Rebel wrote:
Uly wrote:
hyatt wrote:The ENTIRE ENGINE is "the game playing code"
If this was true the ICGA wouldn't have needed to specify "game playing code" in their rule 2.
On top of that it's widely known Rybka's time comtrol is Rybka's Achilles' heel, 'perhaps Vas can't even copy & paste properly :mrgreen:

Obvious statement. I forgot Fruit was using floating point values, remember? He used integer values but copied Fruit's code which had a floating point constant. So he certainly is not "a gifted code copier" at all. "just a code copier" is more accurate.

User avatar
kingliveson
Posts: 1388
Joined: Thu Jun 10, 2010 1:22 am
Real Name: Franklin Titus
Location: 28°32'1"N 81°22'33"W

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by kingliveson » Wed Jan 04, 2012 6:19 pm

Part three is out: http://www.chessbase.com/newsdetail.asp?newsid=7811

"Comparing the UCI parameters for the two engines reveals they are markedly different..." :lol:
PAWN : Knight >> Bishop >> Rook >>Queen

Adam Hair
Posts: 104
Joined: Fri Jun 11, 2010 4:29 am
Real Name: Adam Hair
Contact:

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by Adam Hair » Wed Jan 04, 2012 7:39 pm

A quick question. How is it that a fellow who can not keep up with his source code has an seemingly extensive set of notes detailing his thoughts concerning computer chess programming that date back to 2003?

Jeremy Bernstein
Site Admin
Posts: 1226
Joined: Wed Jun 09, 2010 7:49 am
Real Name: Jeremy Bernstein
Location: Berlin, Germany
Contact:

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by Jeremy Bernstein » Wed Jan 04, 2012 8:13 pm

Crossposting from Talkchess:
Rebel wrote:
bob wrote: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

User avatar
kingliveson
Posts: 1388
Joined: Thu Jun 10, 2010 1:22 am
Real Name: Franklin Titus
Location: 28°32'1"N 81°22'33"W

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by kingliveson » Wed Jan 04, 2012 8:47 pm

"Comparing the UCI parameters for the two engines reveals they are markedly different..."

Make the following changes to Fruit and you'll have the same UCI parameters as Rybka:
diff -abBdEHrw Fruit/eval.cpp Fruit_mod/eval.cpp
147,149c147,149
<    PieceActivityWeight = (option_get_int("Piece Activity") * 256 + 50) / 100;
<    KingSafetyWeight    = (option_get_int("King Safety")    * 256 + 50) / 100;
<    PassedPawnWeight    = (option_get_int("Passed Pawns")   * 256 + 50) / 100;
---
>    PieceActivityWeight = (100 * 256 + 50) / 100;
>    KingSafetyWeight    = (100    * 256 + 50) / 100;
>    PassedPawnWeight    = (100   * 256 + 50) / 100;
diff -abBdEHrw Fruit/material.cpp Fruit_mod/material.cpp
80c80
<    MaterialWeight = (option_get_int("Material") * 256 + 50) / 100;
---
>    MaterialWeight = (100 * 256 + 50) / 100;
diff -abBdEHrw Fruit/option.cpp Fruit_mod/option.cpp
29,30c29,31
<    { "Ponder", true, "false", "check", "", NULL },
< 
---
>    //{ "Ponder", true, "false", "check", "", NULL },
>    { "Search Direction", true, "Very Position", "combo", "var Very Position var Slightly Positional var Slightly Tactical  var Very Tactical", NULL },
>  /*  
54c54
<    { "Passed Pawns",    true, "100", "spin", "min 0 max 400", NULL },
---
>    { "Passed Pawns",    true, "100", "spin", "min 0 max 400", NULL },*/
diff -abBdEHrw Fruit/pawn.cpp Fruit_mod/pawn.cpp
164c164
<    PawnStructureWeight = (option_get_int("Pawn Structure") * 256 + 50) / 100;
---
>    PawnStructureWeight = (100 * 256 + 50) / 100;
diff -abBdEHrw Fruit/protocol.cpp Fruit_mod/protocol.cpp
89c89
< 
---
> 	/*
92c92
<       }
---
>       }*/
diff -abBdEHrw Fruit/pst.cpp Fruit_mod/pst.cpp
111,113c111,113
<    PieceActivityWeight = (option_get_int("Piece Activity") * 256 + 50) / 100;
<    KingSafetyWeight    = (option_get_int("King Safety")    * 256 + 50) / 100;
<    PawnStructureWeight = (option_get_int("Pawn Structure") * 256 + 50) / 100;
---
>    PieceActivityWeight = (100 * 256 + 50) / 100;
>    KingSafetyWeight    = (100 * 256 + 50) / 100;
>    PawnStructureWeight = (100 * 256 + 50) / 100;
diff -abBdEHrw Fruit/search.cpp Fruit_mod/search.cpp
141c141
< 
---
>    /*
161c161
<    }
---
>    }*/
diff -abBdEHrw Fruit/search_full.cpp Fruit_mod/search_full.cpp
128c128
<    string = option_get_string("NullMove Pruning");
---
>   /* string = option_get_string("NullMove Pruning");
134c134
<    } else if (my_string_equal(string,"Fail High")) {
---
>    } else if (my_string_equal(string,"Fail High")) {*/
136c136
<       UseNullEval = true;
---
>       UseNullEval = true;/*
144c144
<    }
---
>    }*/
146c146
<    NullReduction = option_get_int("NullMove Reduction");
---
>    NullReduction = 3;/*
154c154
<    } else if (my_string_equal(string,"Endgame")) {
---
>    } else if (my_string_equal(string,"Endgame")) {*/
156c156
<       UseVerEndgame = true;
---
>       UseVerEndgame = true;/*
164c164
<    }
---
>    }*/
166c166
<    VerReduction = option_get_int("Verification Reduction");
---
>    VerReduction = 5;
170,171c170,171
<    UseHistory = option_get_bool("History Pruning");
<    HistoryValue = (option_get_int("History Threshold") * 16384 + 50) / 100;
---
>    UseHistory = false;
>    HistoryValue = (60 * 16384 + 50) / 100;
175,176c175,176
<    UseFutility = option_get_bool("Futility Pruning");
<    FutilityMargin = option_get_int("Futility Margin");
---
>    UseFutility = false;
>    FutilityMargin = 100;
180,181c180,181
<    UseDelta = option_get_bool("Delta Pruning");
<    DeltaMargin = option_get_int("Delta Margin");
---
>    UseDelta = false;
>    DeltaMargin = 50;
185c185
<    CheckNb = option_get_int("Quiescence Check Plies");
---
>    CheckNb = 1;
Attachments
patch.txt
patch -p1 < patch.txt
(6.58 KiB) Downloaded 198 times
PAWN : Knight >> Bishop >> Rook >>Queen

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by BB+ » Wed Jan 04, 2012 9:35 pm

Comparing the UCI parameters for the two engines reveals they are markedly different...
Let us apply this standard to R3/IPPOLIT... (particularly as Riis tells us the latter is a Rybka-derivative). For matter, let us compare the Rybka 1.6.1 UCI parameters/implementation to that of Rybka 1.0 Beta, and see whether the latter is a derivative of the former...

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by BB+ » Wed Jan 04, 2012 9:36 pm

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

Jeremy Bernstein
Site Admin
Posts: 1226
Joined: Wed Jun 09, 2010 7:49 am
Real Name: Jeremy Bernstein
Location: Berlin, Germany
Contact:

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by Jeremy Bernstein » Wed Jan 04, 2012 10:44 pm

Rebel wrote:
sockmonkey wrote:
Rebel wrote:
bob wrote: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
What an utter nonsense, the documents claim EQUAL PST's using Fruit's modified code. They ARE NOT EQUAL.

Secondly there is no PST code in Rybka.

That you guys fall for it is a mystery.
Prosecution (ICGA): We will prove that Vasik was in Boston at the time of the crime.
Defense (Ed): We can demonstrate without a shadow of a doubt that our client was never in Tijuana.

What do you gain by misrepresenting and distorting the facts, Ed?

jb

User avatar
Harvey Williamson
Posts: 248
Joined: Thu Jun 10, 2010 2:10 pm

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by Harvey Williamson » Wed Jan 04, 2012 10:45 pm

Jeremy Bernstein wrote:
Rebel wrote:
sockmonkey wrote:
Rebel wrote:
bob wrote: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
What an utter nonsense, the documents claim EQUAL PST's using Fruit's modified code. They ARE NOT EQUAL.

Secondly there is no PST code in Rybka.

That you guys fall for it is a mystery.
Prosecution (ICGA): We will prove that Vasik was in Boston at the time of the crime.
Defense (Ed): We can demonstrate without a shadow of a doubt that our client was never in Tijuana.

What do you gain by misrepresenting and distorting the facts, Ed?

jb
My guess is that he postpones his next fall out with Chris W nothing more nothing less :)

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

Re: ChessBase: A Gross Miscarriage of Justice in Computer Ch

Post by Rebel » Wed Jan 04, 2012 11:59 pm

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

Post Reply