ChessBase: A Gross Miscarriage of Justice in Computer Chess

[kingliveson]

This is telling given his affiliation with Rybka. And true, there was no new evidence presented in the opinion piece, or by Mr. Schröder. At this point, nothing short of releasing the source code could exoneration Rybka.

Hi,

http://www.top-5000.nl/evidence.htm#C6

I think that:

Code: Select all

Compile the following code with any of the MS compilers.

static int T=1;
void main() { if (T >= 0.) T=5; }

It will produce the same code as 0.0

is quite interesting.

Also the PST's

http://www.top-5000.nl/pst.htm

For starters

Not sure what is so interesting here. Why shouldn't 0. produce 0.0 or 1. produce 1.0?

GAS LISTING /tmp/cczl8t1E.s 			page 1


   1              		.file	"float.c"
   2              		.text
   3              	.Ltext0:
   4              		.globl	main
   6              	main:
   7              	.LFB0:
   8              		.file 1 "float.c"
   1:float.c      **** #include <stdio.h>
   2:float.c      **** 
   3:float.c      **** void main() 
   4:float.c      **** { 
   9              		.loc 1 4 0
  10              		.cfi_startproc
  11 0000 55       		pushq	%rbp
  12              	.LCFI0:
  13              		.cfi_def_cfa_offset 16
  14              		.cfi_offset 6, -16
  15 0001 4889E5   		movq	%rsp, %rbp
  16              	.LCFI1:
  17              		.cfi_def_cfa_register 6
   5:float.c      ****   int i = 1;
  18              		.loc 1 5 0
  19 0004 C745FC01 		movl	$1, -4(%rbp)
  19      000000
   6:float.c      ****   if (i >= 0.);
  20              		.loc 1 6 0
  21 000b F20F2A45 		cvtsi2sd	-4(%rbp), %xmm0
  21      FC
  22 0010 660F57C9 		xorpd	%xmm1, %xmm1
  23 0014 660F2EC1 		ucomisd	%xmm1, %xmm0
   7:float.c      **** }...
  24              		.loc 1 7 0
  25 0018 5D       		popq	%rbp
  26              	.LCFI2:
  27              		.cfi_def_cfa 7, 8
  28 0019 C3       		ret
  29              		.cfi_endproc
  30              	.LFE0:
  32              	.Letext0:
 245 0000 6F737077 		.string	"ospwG"
 245      4700
 246              		.section	.note.GNU-stack,"",@progbits
GAS LISTING /tmp/cczl8t1E.s 			page 2


DEFINED SYMBOLS
                            *ABS*:0000000000000000 float.c
     /tmp/cczl8t1E.s:6      .text:0000000000000000 main

NO UNDEFINED SYMBOLS

GAS LISTING /tmp/cc4Zmfeb.s 			page 1


   1              		.file	"int.c"
   2              		.text
   3              	.Ltext0:
   4              		.globl	main
   6              	main:
   7              	.LFB0:
   8              		.file 1 "int.c"
   1:int.c      **** #include <stdio.h>
   2:int.c      **** 
   3:int.c      **** void main() 
   4:int.c      **** { 
   9              		.loc 1 4 0
  10              		.cfi_startproc
  11 0000 55       		pushq	%rbp
  12              	.LCFI0:
  13              		.cfi_def_cfa_offset 16
  14              		.cfi_offset 6, -16
  15 0001 4889E5   		movq	%rsp, %rbp
  16              	.LCFI1:
  17              		.cfi_def_cfa_register 6
   5:int.c      ****   int i = 1;
  18              		.loc 1 5 0
  19 0004 C745FC01 		movl	$1, -4(%rbp)
  19      000000
   6:int.c      ****   if (i >= 0);
   7:int.c      **** }...
  20              		.loc 1 7 0
  21 000b 5D       		popq	%rbp
  22              	.LCFI2:
  23              		.cfi_def_cfa 7, 8
  24 000c C3       		ret
  25              		.cfi_endproc
  26              	.LFE0:
  28              	.Letext0:
 241 0000 6F737077 		.string	"ospwG"
 241      4700
 242              		.section	.note.GNU-stack,"",@progbits
GAS LISTING /tmp/cc4Zmfeb.s 			page 2


DEFINED SYMBOLS
                            *ABS*:0000000000000000 int.c
     /tmp/cc4Zmfeb.s:6      .text:0000000000000000 main

NO UNDEFINED SYMBOLS

As enticing and tempting as this is, unfortunately, I cannot indulge in the regurgitated speculations. Rather than basing your rebuttal on a typo, please join in calling for the source code release.

[Jeremy Bernstein]

German article from the summer which I never saw, mentioned on the CSS forum: http://diepresse.com/home/spectrum/spie ... -Fischchen. Nothing really new here, but a few interesting tidbits. Again, we see that the critics of the ICGA's verdict offer only institutional criticism and "a bad feeling" to counter the evidence of code copying provided by the panel.

[Rebel]

Not sure what is so interesting here. Why shouldn't 0. produce 0.0 or 1. produce 1.0?

...

As enticing and tempting as this is, unfortunately, I cannot indulge in the regurgitated speculations. Rather than basing your rebuttal on a typo, please join in calling for the source code release.

As you know (I assume you do) the 0.0 case among programmers was one of the strongest evidences for copying. The point is that 0.0 (2 key-strokes as a typo) is now limited to one overlooked dot typo on a 1920-1080 screen. 0.0 can't be proven any longer, only 0.

Together with the fact that the code that surrounds 0. is not Fruit + the fact Vas the great obfuscator already in 2005 foresaw his program would be hacked multiple times and thus moved from a superior (float) time control to an inferior (int) time control with known issues is enough to close the case. That is of course if you think VII.

[Uly]

And even if it was, the 0.0 is in the middle of non-playing code, so the 0.0 or any other copied part in there couldn't break ICGA's rule 2.

[Jeremy Bernstein]

Part 2 is out: http://www.chessbase.com/newsdetail.asp?newsid=7807

[thorstenczub]

ChessBase on the Rybka/Fruit controversy: http://www.chessbase.com/newsdetail.asp?newsid=7791

As Jeremy said, "In the new article, they should have mentioned that a) Søren is a moderator on the Rybka Forum and b) ChessBase is a distributor of Rybka and in no way impartial."

but chess base has no interest in objective articles, instead they live from selling new software.

[Jeremy Bernstein]

ChessBase on the Rybka/Fruit controversy: http://www.chessbase.com/newsdetail.asp?newsid=7791

As Jeremy said, "In the new article, they should have mentioned that a) Søren is a moderator on the Rybka Forum and b) ChessBase is a distributor of Rybka and in no way impartial."

but chess base has no interest in objective articles, instead they live from selling new software.

Yes, that was my point: they should disclose that they, as the publisher, stand to gain financially by the publication of an "exoneration" of Rybka. I've read the 2nd part now. Lots of sizzle, not much steak.

[kingliveson]

Part 2 is out: http://www.chessbase.com/newsdetail.asp?newsid=7807

Trying to re-write history I see... He forgot that that same dendrogram convicted Fritz (ChessBase product) of being a Strelka clone.

[Jeremy Bernstein]

Part 2 is out: http://www.chessbase.com/newsdetail.asp?newsid=7807

Trying to re-write history I see... He forgot that that same dendrogram convicted Fritz (ChessBase product) of being a Strelka clone.

Ha! Good catch. Make sure to send that observation to the CB newsroom comment box.

[hyatt]

He is repeating past false statements, and referring to the "king of false statements" by referencing Ed's web page which is intentionally misleading and unsound.

Can you elaborate? I didn't find anything false in Ed's pages.

One simple one.

Take one PST from Fruit. The initialization code can be modified by changing four constants, and EXACTLY produces the PST values for the same Rybka PST. Here is where Ed's page is blatantly wrong..

A single PST value is computed like this:

square = rank_mult * constant1 + file_mult * constant1 + rank_mult * constant2 + rank_mult * constant3 + constant4

Ed presumes to take the fruit value for square, and the rybka value for square, and show they are not equal by dividing the rybka value by a single constant. If you look at the math above, since a single square's value is the sum of 5 different multiply operations. How can you divide by a SINGLE constant to convert from Rybka to Fruit? Answer: You can't. And anyone that has looked at the fruit code understands this. For the record, here is the fruit knight PST initialization so that you can see what is being done...

// knights

piece = WhiteKnight12;

// centre

for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) += KnightLine[square_file(sq)] * KnightCentreOpening;
P(piece,sq,Opening) += KnightLine[square_rank(sq)] * KnightCentreOpening;
P(piece,sq,Endgame) += KnightLine[square_file(sq)] * KnightCentreEndgame;
for (sq = 0; sq < 64; sq++) {
P(piece,sq,Opening) += KnightRank[square_rank(sq)] * KnightRankOpening;
}

// back rank

for (sq = A1; sq <= H1; sq++) { // HACK: only first rank
P(piece,sq,Opening) -= KnightBackRankOpening;
}

// "trapped"

P(piece,A8,Opening) -= KnightTrapped;
P(piece,H8,Opening) -= KnightTrapped;


If you look at the code, which I simplified for a single value, you can see the problem.

One can't take the above "square" value I computed, where each square uses the SAME 4 constants, but different rank/file multipliers, and sums them, and then divide by a single constant to reduce to a "fruit value".

For example, one that is simpler,

v1 = 2 * 13 + 3 * 2 (suppose this produces a fruit value, result = 32)
v2 = 3 * 13 + 4 * 2 (a different square fruit value, result = 47)

For Rybke we could do

v1 = 2 * 147 + 3 * 21 (result = 357)
v2 = 3 * 147 + 4 * 21 (result = 525)

What constant do you divide those by to get the fruit values? Notice that both use the same multipliers, but the two constants (13 and 2 for fruit) were changed to 147 and 21 for Rybka) (and note this is a simplified example, none of those numbers come from fruit or rybka.)

You could divide the first rybka number by the first fruit value, which gives 11.15625. Or you could divide the second rybka number by the second fruit number, which gives 11.170212766. So which "divisor" do you use? Answer: Neither. There IS no single divisor that will convert each number from Rybka to Fruit. Yet this is exactly what Ed uses to show that the Rybka and Fruit PSTs are "not equivalent."

I'd expect that ANYONE with basic math skills to understand that. Which means that either (a) he knows nothing about math or (b) he is being blatantly dishonest. Either is bad. In the former case, he ought not be investigating ANYTHING if he can't understand basic math; in the latter case, well, you understand the implication of that case...