FIDE Rules on ICGA - Rybka controversy

[Chris Whittington]

it becomes Vas verbatim copied Fruit (the real accusation)

This is only the "real accusation" to you. "Verbatim copying" was never the point of the matter for the ICGA. It was never the point of the matter for Letouzey. Even his words (regarding Strelka) make clear that Strelka/Rybka was not a direct copy, but a "copy with different words" (like a translation). This is only about the 100th time you've made this claim, I guess if you repeat enough you think someone else might believe it.

Regarding Soren, I don't know why you are constantly are picking on him.

I do not think I am picking on him. He made a significant number of substantial errors in his ChessBase article (any of which would greatly mislead someone interested in forming their opinion based upon the actual facts), and repeated many of them in his Entertainment Computing article (even when corrected by Levy or myself in our rebuttals). I would use the term "grossly incompetent", but you would probably just think it is a term of art, rather than having a specific meaning (as in "not competent", and in a "gross" manner, particularly for a computer scientist). If you want me to cite (technical) examples, well, I already did so in my rebuttal, but I will be happy to copy 30 or 40 of them here.

And regarding your complaint to Chessbase about Soren's article, you got your rebuttal, didn't you?

No. The ICGA published my technical rebuttal to Riis. ChessBase had nothing to do with it (and later even published his comments on my work, ostensibly in response to Levy's interview, though they eventually removed the libelous remarks he made therein regarding me).

And if I may add, Soren's article was brilliant to the audience it was directed. Try to explain a technical case ... On a scale of 10 I would give it a 9+ for a bunch of non chess programmers.

Unfortunately, it was based upon false statements and outright lies regarding the technical evidence. If this is your definition of "brilliant", I can only conclude that the word "truth" is essentially meaningless to you. I would give it 0 out of 10, for it did nothing but mislead the reader concerning the evidence. Riis did not "explain a technical case" in any sense, instead he (gravely) mis-represented what the Rybka/Fruit case was about. Even if was OK for ChessBase as a (rabidly) pro-Rybka piece, it was garbage for an ostensibly "research article" as he later published in Entertainment Computing.

And about your rebuttal, well, it's understandable that you did, but of course Soren (a non programmer) is no match for you when it comes down to some of the technical aspects.

Then why did he present himself (quite superciliously) as a master of said technical aspects, and spend time "refuting" the claims therein (many of which weren't actually relevant to the ICGA decision)? If he knew nothing about the technical aspects, perhaps he should just be silent about them (indeed, as you/Dalke convinced me that I should have done regarding copyright). Instead, he presented many technical points quite falsely to the ChessBase audience. And if you don't understand the technical aspects, most likely you don't understand the case at all!

Instead, why don't you try me and and write a rebuttal about the contra investigation, whole different game. But I predict you will pass, like Levy passed.

I have already explained to you why the "contra investigation" is garbage. I would agree with anyone who says that Rybka Reloaded is a waste of time to read.

Briefly: Introduction, quotes Dalke, who specifically said he didn't care about the ICGA decision (only GPL), thus mostly irrelevant. Pages 5-49, you largely do not argue against Zach's claims, only that "verbatim copying" was not done. I could pick out some specifics on other matters, such as your claims regarding PST, but I think they have already been discussed other places (like in my rebuttal to Riis), and nothing new is really said. For the "code copying", let's take a specific place, say the bottom of page 28 (in Material) when you say: As already stated everything is different as the code itself shows. We don't understand the relevance if your goal is to proof code theft, this more or less is evidence of the opposite, original ideas [MIT] and own code. It was never the goal, of Zach's work, my work, the ICGA investigation, or Letouzey's open letter, to prove "code theft", so your (long) ramblings are irrelevant. Similarly on page 42: If one wants to make a case for code theft this isn't a very good example. As the ICGA didn't make "a case for code theft", your comment is irrelevant.

Chapter II, about my RYBKA_FRUIT, you again talk about "copy theft", and you do not mention EVAL_COMP. I don''t see anything relevant here. Section 3, I already pointed out your "neglectful 3%" distortion, and your imagined "red zone" with no statistical quantification of it. Furthermore, I think the DHW paper covers the topic much more fully than you do. Chapter 4 (historic evidence) is not relevant, it again just argues that there are worse copy jobs than Rybka/Fruit (also, LION++ was not a "copyright breach", given the GPL aspect). Chapter 5, I have already pointed out how silly your list of "36 indisputable differences" is. You could easily make "a million indisputable differences" by pointing that bits 0,3,4,7,13,17,19,22,23,24,27,.... in the executables differ. And with the last chapter, again I answered it above, it is the same error as in Chapter 4, you are only arguing that Fruit/Rybka is not as bad as X/Y, which is a different argument than disputing whether Rybka had its origins in Fruit.

I don't see any reason to continue posting on this matter. As long as you are arguing about "code theft", and/or comparing Rybka/Fruit to direct clones, the relevance of your work to the ICGA investigation and decision is almost nil.

The flame war versus the academic bitch fight.

Personally, I find passively viewing flame wars can be quite fun, especially if each of the posts are short, sharp and to the point. One paragraph or so, with stingy barb at the end. Academic bitch fights on the other hand are so pedantic, lengthy and tedious. Lousy as a spectator sport. Similar to watching flamingoes squabbling whilst preening at the same time.

[Rebel]

And therefore they signed the letter. The heart of the complaint is not the Fruit ideas in Rybka, the heart of the complaint is that they believed Vas copied.

Fabien's open letter (and the ensuing TalkChess thread, linked to by the Programmer's Open Letter) already make it clear that it is not about "code copying"

I beg your pardon?

I already hinted to you to read page 38 of the first PDF document, apparently you did not follow the lead or whatever, but here are Fabien's exact words:

~~~~~~~~~~~~~~~~~~~~~~~

Hi Ed,

Yes, this is my conjecture from looking at the Strelka source code which as confirmed by experts is a faithful C
translation of the Rybka binary:

1) Vasik took the Fruit 2.1 public source code
2) he removed everything that did not hurt Elo rating and could gain some speed
3) he moved all possible code into static tables or hashable stuff (e.g. pawn shield/storms were moved to hashed
pawn eval)
4) he converted the board to bitboards, probably by maintaining the two data structures until he finished the
conversion
5) he (probably) manually inlined some other stuff

Examples of 2) are collecting the PV during search, mate-distance pruning and underpromotions (this makes
move generation faster by avoiding having to test for promotion at all).

The rationale of this process is as follows:
a) speed is the priority; Fruit is slow and simply making it faster is a simple way to get to the top of rating lists
b) simplify the code as much as possible (move to tables, inline), this will help compiler optimisation too; Fruit was
designed with future development in mind so it had many unnecessary function calls
c) obfuscation was less of a priority; usually a) and b) automatically bring c)
d) it's possible to test the engine at anytime to make sure no big mistake was made

About c), it seems Vasik cared about hiding copied Fruit code like UCI parsing only after Strelka appeared. He
considered a binary was safe enough from investigation.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Capiche?

[Rebel]

I don't see any reason to continue posting on this matter. As long as you are arguing about "code theft", and/or comparing Rybka/Fruit to direct clones, the relevance of your work to the ICGA investigation and decision is almost nil.

Then don't deny the reality of that. You are relative new in this world. I have dwelled among them for 25 years. I know them personally. I know what moves them, what upsets them, pretty much the same as me. And I have been in your VIG camp remember? I know exactly how they think, what they think, also about this case, cryptic rule #2 became the stick to beat Vas for copying Fruit. It's what they believed and I can give you the public quotes of Zach, Bob, Lefler (to name a few) that proofs it. And even you, although more careful have hinted to that, for example:

1. Mark Watkins: It also seems (see node counts and depth) that Rajlich did in fact have "obfuscation" as one of the things on his mind during this period [though maybe just externally].

2. Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty, particularly when combined with the various other Fruit 2.1 bits that appear here-and-there in Rybka 1.0 Beta.

~~~~~~~~~~~~~~~~~~~~~~

So then following your wish let's talk about rule #2.

My main beef with your and Zach's document:

Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty,

Zach Wegner: Simply put, Rybka's evaluation is virtually identical to Fruit's.

And more of this type of qualifications.

Then when we go in depth and let's take the code snippet already posted, the evaluation of open c.q. semi open rook files:

Code: Select all

// Start ROOK eval   [ RYBKA 1.0 ]
// ===============
		
if (!(v84 & HIDWORD(qword_667BA0[0]) | v83 & qword_667BA0[0]) ) // open / semi open rook files
  {                       // when semi-open
     v271 += 256;         // endgame+256	
     v6 += 64;            // opening+64 }
 
if ( !(v84 & HIDWORD(qword_667BA8[0]) | v83 & qword_667BA8[0]) )
  {                       // when open file
    v6 += 971;            // opening+971
    v271 += 172;          // endgame+172  }

So what is evaluated here? Simple public available chess knowledge you will find in chess teachings books to put your rooks on open files and the less open files (expressed in this case via MG/EG, a public available technique introduced in Phalanx, predating Fruit and Rybka with 4-5 years) the more important it becomes. Every reasonable open source has it, no big secret, so has Fruit, so has Rybka, so have I since the early 80's. Rook (semi) open file evaluation in a most simply form, common chess knowledge.

And it's coded differently even if we remove the mailbox-bitboard difference, as Sven Schuele correctly pointed out:

Regarding the "rook on open file" evaluation, both Zach Wegner and Mark Watkins have observed correctly that there is an important difference between Fruit in Rybka, in contrast to Fruit, Rybka does NOT consider friendly pawns behind the rook (e.g. Ra3, Pa2) to determine a "semi-open file" or "open file".

The Zach Wegner Rybka equivalent code seems to reflect that correctly if we assume that the bitmask mask_open_file_w[square] has all white pawns on ranks lower than 'square' masked out. Since the assembler code would match the "Zach Wegner code" it seems to be plausible. BUT the major point is, this Fruit-Rybka difference is indeed a SEMANTICAL DIFFERENCE.

~~~~~~~~~~~~~~~~

I mean, seriously, this is tunnel vision | VIG thinking. How can common chess knowledge fall under the interpretation of rule #2 which is about originality? There is no originality in chess knowledge, it's fixed, you better follow the rules of the books that teach chess else your engine will perform bad.

I could go on, I can post a dozen of other examples (as above) where (especially) Zach reasoned this way to incriminate Rybka while in reality it's about common chess knowledge and coded DIFFERENTLY than in Fruit even after removing the mailbox / bitboard difference.

What the hell does rule #2 mean?

[hyatt]

22. The programs have different Zobrist hash keys.
23. The programs have different user interface options.

Well, at least these last two were so ridiculous (or added too late) that you didn't have Riis copy them over to his Entertainment Computing article.

I tell you what really ridiculous is - when I just explained (to you) why I collect differences between Rybka and Fruit, that the more I find, the more unlikely it becomes Vas verbatim copied Fruit (the real accusation) and that in a deveopment period of only 5½ months.

Regarding Soren, I don't know why you are constantly are picking on him. I haven't read the article you refer to so I can't judge. And regarding your complaint to Chessbase about Soren's article, you got your rebuttal, didn't you?

And if I may add, Soren's article was brilliant to the audience it was directed. Try to explain a technical case only understandable for (chess) programmers provided they have invested CONSIDERABLE time and then in the end after 4 years still can't reach a consensus and that to the average Chessbase reader, that's almost mission impossible. That group did a fantastic job. On a scale of 10 I would give it a 9+ for a bunch of non chess programmers.

And about your rebuttal, well, it's understandable that you did, but of course Soren (a non programmer) is no match for you when it comes down to some of the technical aspects. Instead, why don't you try me and and write a rebuttal about the contra investigation, whole different game. But I predict you will pass, like Levy passed.

Doesn't that say EVERYTHING here? "Soren (a non-programmer)" getting involved in a technical discussion that can ONLY be understood by programmers. Of course that explains the complete lack of veracity in his "article". He should also write an article explaining why direct connections between a computer and human brain tissue can not be done, he'd probably know JUST AS MUCH about that specific topic so in his world he would be well-qualified to explain that to the "non-technical readers" I presume?

[hyatt]

And therefore they signed the letter. The heart of the complaint is not the Fruit ideas in Rybka, the heart of the complaint is that they believed Vas copied.

Fabien's open letter (and the ensuing TalkChess thread, linked to by the Programmer's Open Letter) already make it clear that it is not about "code copying"

I beg your pardon?

I already hinted to you to read page 38 of the first PDF document, apparently you did not follow the lead or whatever, but here are Fabien's exact words:

~~~~~~~~~~~~~~~~~~~~~~~

Hi Ed,

Yes, this is my conjecture from looking at the Strelka source code which as confirmed by experts is a faithful C
translation of the Rybka binary:

1) Vasik took the Fruit 2.1 public source code
2) he removed everything that did not hurt Elo rating and could gain some speed
3) he moved all possible code into static tables or hashable stuff (e.g. pawn shield/storms were moved to hashed
pawn eval)
4) he converted the board to bitboards, probably by maintaining the two data structures until he finished the
conversion
5) he (probably) manually inlined some other stuff

Examples of 2) are collecting the PV during search, mate-distance pruning and underpromotions (this makes
move generation faster by avoiding having to test for promotion at all).

The rationale of this process is as follows:
a) speed is the priority; Fruit is slow and simply making it faster is a simple way to get to the top of rating lists
b) simplify the code as much as possible (move to tables, inline), this will help compiler optimisation too; Fruit was
designed with future development in mind so it had many unnecessary function calls
c) obfuscation was less of a priority; usually a) and b) automatically bring c)
d) it's possible to test the engine at anytime to make sure no big mistake was made

About c), it seems Vasik cared about hiding copied Fruit code like UCI parsing only after Strelka appeared. He
considered a binary was safe enough from investigation.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Capiche?

We seem to. YOU don't. Read your quote carefully. "removed everything that did not...", "moved all possible code to static tables...", "converted to bit boards..." "inlined some other stuff".

And yet you are looking for EXACT code matches??? That is MY complaint with your top-500 stuff. self-contradictions everywhere. You should remove ALL references to "semantic equivalence" since no examples are correct. EG/MG interpolation has NOTHING to do with "semantic equivalence". That's an idea, not semantics. Fabian's letter is not suggesting "he copied and ran with it." It suggests that he copied, rewrite big parts due to bit board conversion, optimized other parts (more changes) and then tried to hide the similarities with his infamous node count, depth and PV obfuscation.

And yet you look for exact code matches??? That's why the investigation too so long. Zach's task was NOT an easy one.

[hyatt]

I don't see any reason to continue posting on this matter. As long as you are arguing about "code theft", and/or comparing Rybka/Fruit to direct clones, the relevance of your work to the ICGA investigation and decision is almost nil.

Then don't deny the reality of that. You are relative new in this world. I have dwelled among them for 25 years. I know them personally. I know what moves them, what upsets them, pretty much the same as me. And I have been in your VIG camp remember? I know exactly how they think, what they think, also about this case, cryptic rule #2 became the stick to beat Vas for copying Fruit. It's what they believed and I can give you the public quotes of Zach, Bob, Lefler (to name a few) that proofs it. And even you, although more careful have hinted to that, for example:

1. Mark Watkins: It also seems (see node counts and depth) that Rajlich did in fact have "obfuscation" as one of the things on his mind during this period [though maybe just externally].

2. Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty, particularly when combined with the various other Fruit 2.1 bits that appear here-and-there in Rybka 1.0 Beta.

~~~~~~~~~~~~~~~~~~~~~~

So then following your wish let's talk about rule #2.

My main beef with your and Zach's document:

Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty,

Zach Wegner: Simply put, Rybka's evaluation is virtually identical to Fruit's.

And more of this type of qualifications.

Then when we go in depth and let's take the code snippet already posted, the evaluation of open c.q. semi open rook files:

Code: Select all

// Start ROOK eval   [ RYBKA 1.0 ]
// ===============
		
if (!(v84 & HIDWORD(qword_667BA0[0]) | v83 & qword_667BA0[0]) ) // open / semi open rook files
  {                       // when semi-open
     v271 += 256;         // endgame+256	
     v6 += 64;            // opening+64 }
 
if ( !(v84 & HIDWORD(qword_667BA8[0]) | v83 & qword_667BA8[0]) )
  {                       // when open file
    v6 += 971;            // opening+971
    v271 += 172;          // endgame+172  }

So what is evaluated here? Simple public available chess knowledge you will find in chess teachings books to put your rooks on open files and the less open files (expressed in this case via MG/EG, a public available technique introduced in Phalanx, predating Fruit and Rybka with 4-5 years) the more important it becomes. Every reasonable open source has it, no big secret, so has Fruit, so has Rybka, so have I since the early 80's. Rook (semi) open file evaluation in a most simply form, common chess knowledge.

And it's coded differently even if we remove the mailbox-bitboard difference, as Sven Schuele correctly pointed out:

Regarding the "rook on open file" evaluation, both Zach Wegner and Mark Watkins have observed correctly that there is an important difference between Fruit in Rybka, in contrast to Fruit, Rybka does NOT consider friendly pawns behind the rook (e.g. Ra3, Pa2) to determine a "semi-open file" or "open file".

The Zach Wegner Rybka equivalent code seems to reflect that correctly if we assume that the bitmask mask_open_file_w[square] has all white pawns on ranks lower than 'square' masked out. Since the assembler code would match the "Zach Wegner code" it seems to be plausible. BUT the major point is, this Fruit-Rybka difference is indeed a SEMANTICAL DIFFERENCE.

~~~~~~~~~~~~~~~~

I mean, seriously, this is tunnel vision | VIG thinking. How can common chess knowledge fall under the interpretation of rule #2 which is about originality? There is no originality in chess knowledge, it's fixed, you better follow the rules of the books that teach chess else your engine will perform bad.

I could go on, I can post a dozen of other examples (as above) where (especially) Zach reasoned this way to incriminate Rybka while in reality it's about common chess knowledge and coded DIFFERENTLY than in Fruit even after removing the mailbox / bitboard difference.

What the hell does rule #2 mean?

It really means what it says. In your "code snippet" again, that snippet BY ITSELF doesn't mean much. What does "mean much" is to compare the rybka binary and the fruit source and notice how those things are done in the same order. So what if he later decided to slightly alter that term by excluding pawns behind the rook? We already KNEW he had made changes, since Rybka was stronger than Fruit, so that's not exactly headline material. This is sort of like taking (say) a 500 piece puzzle. Buy two of the same. Open box number one and remove 100 pieces. Then open box two and remove 100 pieces. Now your task becomes "are these two puzzles basically the same picture, even with all the missing parts?" Let's go even further. Insert 100 pieces from ANOTHER puzzle into both boxes. Our approach was to try to figure out where the pieces go in each puzzle, and when we find one that didn't fit, set it aside. When we finish we end up with two puzzles that have 400 pieces in them plus some holes. The holes are in different places. But when you "intersect" the two puzzles, can you decide whether or not they are the same picture or not? I can. You want to take ONE of those "extra pieces" and say "this doesn't match any piece in the other box, clearly these are not the same two puzzles. In our comparison, differences did not matter, similarities were the thing we were looking for. IE I don't care if you go stick a pink and blue fake exhaust pipe on the back of your car, it is STILL the same vehicle, it is not new and original.

[Chris Whittington]

I don't see any reason to continue posting on this matter. As long as you are arguing about "code theft", and/or comparing Rybka/Fruit to direct clones, the relevance of your work to the ICGA investigation and decision is almost nil.

Then don't deny the reality of that. You are relative new in this world. I have dwelled among them for 25 years. I know them personally. I know what moves them, what upsets them, pretty much the same as me. And I have been in your VIG camp remember? I know exactly how they think, what they think, also about this case, cryptic rule #2 became the stick to beat Vas for copying Fruit. It's what they believed and I can give you the public quotes of Zach, Bob, Lefler (to name a few) that proofs it. And even you, although more careful have hinted to that, for example:

1. Mark Watkins: It also seems (see node counts and depth) that Rajlich did in fact have "obfuscation" as one of the things on his mind during this period [though maybe just externally].

2. Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty, particularly when combined with the various other Fruit 2.1 bits that appear here-and-there in Rybka 1.0 Beta.

~~~~~~~~~~~~~~~~~~~~~~

So then following your wish let's talk about rule #2.

My main beef with your and Zach's document:

Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty,

Zach Wegner: Simply put, Rybka's evaluation is virtually identical to Fruit's.

And more of this type of qualifications.

Then when we go in depth and let's take the code snippet already posted, the evaluation of open c.q. semi open rook files:

Code: Select all

// Start ROOK eval   [ RYBKA 1.0 ]
// ===============
		
if (!(v84 & HIDWORD(qword_667BA0[0]) | v83 & qword_667BA0[0]) ) // open / semi open rook files
  {                       // when semi-open
     v271 += 256;         // endgame+256	
     v6 += 64;            // opening+64 }
 
if ( !(v84 & HIDWORD(qword_667BA8[0]) | v83 & qword_667BA8[0]) )
  {                       // when open file
    v6 += 971;            // opening+971
    v271 += 172;          // endgame+172  }

So what is evaluated here? Simple public available chess knowledge you will find in chess teachings books to put your rooks on open files and the less open files (expressed in this case via MG/EG, a public available technique introduced in Phalanx, predating Fruit and Rybka with 4-5 years) the more important it becomes. Every reasonable open source has it, no big secret, so has Fruit, so has Rybka, so have I since the early 80's. Rook (semi) open file evaluation in a most simply form, common chess knowledge.

And it's coded differently even if we remove the mailbox-bitboard difference, as Sven Schuele correctly pointed out:

Regarding the "rook on open file" evaluation, both Zach Wegner and Mark Watkins have observed correctly that there is an important difference between Fruit in Rybka, in contrast to Fruit, Rybka does NOT consider friendly pawns behind the rook (e.g. Ra3, Pa2) to determine a "semi-open file" or "open file".

The Zach Wegner Rybka equivalent code seems to reflect that correctly if we assume that the bitmask mask_open_file_w[square] has all white pawns on ranks lower than 'square' masked out. Since the assembler code would match the "Zach Wegner code" it seems to be plausible. BUT the major point is, this Fruit-Rybka difference is indeed a SEMANTICAL DIFFERENCE.

~~~~~~~~~~~~~~~~

I mean, seriously, this is tunnel vision | VIG thinking. How can common chess knowledge fall under the interpretation of rule #2 which is about originality? There is no originality in chess knowledge, it's fixed, you better follow the rules of the books that teach chess else your engine will perform bad.

I could go on, I can post a dozen of other examples (as above) where (especially) Zach reasoned this way to incriminate Rybka while in reality it's about common chess knowledge and coded DIFFERENTLY than in Fruit even after removing the mailbox / bitboard difference.

What the hell does rule #2 mean?

It really means what it says. In your "code snippet" again, that snippet BY ITSELF doesn't mean much. What does "mean much" is to compare the rybka binary and the fruit source and notice how those things are done in the same order. So what if he later decided to slightly alter that term by excluding pawns behind the rook? We already KNEW he had made changes, since Rybka was stronger than Fruit, so that's not exactly headline material. This is sort of like taking (say) a 500 piece puzzle. Buy two of the same. Open box number one and remove 100 pieces. Then open box two and remove 100 pieces. Now your task becomes "are these two puzzles basically the same picture, even with all the missing parts?" Let's go even further. Insert 100 pieces from ANOTHER puzzle into both boxes. Our approach was to try to figure out where the pieces go in each puzzle, and when we find one that didn't fit, set it aside. When we finish we end up with two puzzles that have 400 pieces in them plus some holes. The holes are in different places. But when you "intersect" the two puzzles, can you decide whether or not they are the same picture or not? I can. You want to take ONE of those "extra pieces" and say "this doesn't match any piece in the other box, clearly these are not the same two puzzles. In our comparison, differences did not matter, similarities were the thing we were looking for. IE I don't care if you go stick a pink and blue fake exhaust pipe on the back of your car, it is STILL the same vehicle, it is not new and original.

Fiddlesticks. You can hardly play chess so you still can't understand what Rybka does here. Mark Watkins missed it's importance completely. And Zach dismissed it as rare and unimportant.

Every chess program on the planet tests for open files and semi-open files.
Rybka doesn't make this test at all. Rybka is different here to EVERYTHING. Only you don't realise it.

To explain it to you, read VERY carefully, slowly and think:

Imagine an almost closed pawn structure, seven pawns per side, mostly locked into contact positions, but with one open file. A common theme, this and sub-variants of it.
Every chess program will, in it pawn-rook interaction code (that you call open and half open file):
give a rook a BONUS for being on the open file,
ZERO BONUS for being behind its own pawns,
the same ZERO bonus for being behind the enemy pawns.

Meanwhile every chess player will
give a rook a BONUS for being on the open file,
ZERO BONUS for being behind its own pawns,
and a POSITIVE BONUS for being behind the enemy pawns

In others, the chess player wants to get his rook into AND BEHIND the enemy pawns. He realises, unlike ALL CHESS PROGRAMS with this code that being behind hsi own pawns is pretty useless.

Rybka will behave not like ALL the other chess programs, but like ALL chess players. hahahahahahahaha!!!

And you call this "semantically equivalent" or "slightly altered" or "rare and not very important"?! hahahahahahaha!!!

It's obviously not copied code, it's a new idea and it's self created code and it's way stronger and way better than any rook-pawn code written before it. Stop being so ridiculous. You don't get 100's of ELO points by copying, you get 100's of ELO points by creative originality, originality which NONE OF YOU spotted. Copied! Pfah!!

[Chris Whittington]

22. The programs have different Zobrist hash keys.
23. The programs have different user interface options.

Well, at least these last two were so ridiculous (or added too late) that you didn't have Riis copy them over to his Entertainment Computing article.

I tell you what really ridiculous is - when I just explained (to you) why I collect differences between Rybka and Fruit, that the more I find, the more unlikely it becomes Vas verbatim copied Fruit (the real accusation) and that in a deveopment period of only 5½ months.

Regarding Soren, I don't know why you are constantly are picking on him. I haven't read the article you refer to so I can't judge. And regarding your complaint to Chessbase about Soren's article, you got your rebuttal, didn't you?

And if I may add, Soren's article was brilliant to the audience it was directed. Try to explain a technical case only understandable for (chess) programmers provided they have invested CONSIDERABLE time and then in the end after 4 years still can't reach a consensus and that to the average Chessbase reader, that's almost mission impossible. That group did a fantastic job. On a scale of 10 I would give it a 9+ for a bunch of non chess programmers.

And about your rebuttal, well, it's understandable that you did, but of course Soren (a non programmer) is no match for you when it comes down to some of the technical aspects. Instead, why don't you try me and and write a rebuttal about the contra investigation, whole different game. But I predict you will pass, like Levy passed.

Doesn't that say EVERYTHING here? "Soren (a non-programmer)" getting involved in a technical discussion that can ONLY be understood by programmers. Of course that explains the complete lack of veracity in his "article". He should also write an article explaining why direct connections between a computer and human brain tissue can not be done, he'd probably know JUST AS MUCH about that specific topic so in his world he would be well-qualified to explain that to the "non-technical readers" I presume?

Hilariously ironic!! Soren should shut up because he can't discuss technicals with programmers! This from someone who can hardly play chess at any reasonable level trying, and failing, to analyse the CHESS programming of an International Master.

[Rebel]

Doesn't that say EVERYTHING here? "Soren (a non-programmer)" getting involved in a technical discussion that can ONLY be understood by programmers. Of course that explains the complete lack of veracity in his "article". He should also write an article explaining why direct connections between a computer and human brain tissue can not be done, he'd probably know JUST AS MUCH about that specific topic so in his world he would be well-qualified to explain that to the "non-technical readers" I presume?

Have you read it? What about the criticism on rule #2?

http://en.chessbase.com/post/a-gro-misc ... -part-one-

For a non-specialist, including tournament directors and other ICGA board members, the flaws in Rule 2 might not be so obvious. However, to begin to understand the problem with Rule 2 one can start by acknowledging the truth contained within Rajlich’s remark on this topic:

When two modern top chess programs play against each other maybe 95% of the programs are algorithmically the same. What is classing is the other 5%.

Putting it bluntly, Rule 2 has become obsolete. It is completely vague or unrealistic on critical points that have emerged in recent years, or have always existed but were not as well understood in the past. Years ago, because of the way chess programs were traditionally developed, it was much easier to identify fraudulent entries and programmer-poseurs. Perhaps in that era Rule 2 was quite sufficient to expel entries not meeting originality standards. But, as will be shown, times have changed in computer chess and some of the old standards have been undermined or supplanted due to advances in information technology.

To make Rule 2’s absurdity as clear as possible, let me pose some straightforward questions:

•Given the great algorithmic overlap between modern chess programs, what is the definitional distinction between “original” and “non-original” work?

•A modern computer chess program can consist of tens of thousands of lines of code. Which of these lines can a programmer feel certain are in public domain and therefore exempt from Rule 2, and which are not?

•What exactly is meant by “game playing code” and on what basis does the ICGA make its distinction?

•What exactly is the definition of a “close derivative”? Is this phrase entirely a “we know it when we see it” construct, and if not, then what sensible, consistent, well-defined and articulated principles is such a determination based upon?

•Does Rule 2 require all competitors to maintain a copy of any source code they used in competition for an indefinite number of years?

•Can Rule 2 be invoked after tournaments are completed without any time limitation whatsoever? (In law, there is a defense called laches, which certainly applies to the Rajlich/Rybka case.)

• Finally, what safeguards exist to prevent ex post facto interpretations of rules which are not fully consistent with what competitors understood at the time the tournament took place?

It seems to me rather imperative that a tournament billing itself a “world championship” have crystal-clear rules. These rules should evolve in response to circumstances, contain well-defined procedures and credible enforcement mechanisms, and be designed to protect the integrity of the competition and the title.

[Rebel]

What the hell does rule #2 mean?

It really means what it says. In your "code snippet" again, that snippet BY ITSELF doesn't mean much. What does "mean much" is to compare the rybka binary and the fruit source and notice how those things are done in the same order. So what if he later decided to slightly alter that term by excluding pawns behind the rook? We already KNEW he had made changes, since Rybka was stronger than Fruit, so that's not exactly headline material. This is sort of like taking (say) a 500 piece puzzle. Buy two of the same. Open box number one and remove 100 pieces. Then open box two and remove 100 pieces. Now your task becomes "are these two puzzles basically the same picture, even with all the missing parts?" Let's go even further. Insert 100 pieces from ANOTHER puzzle into both boxes. Our approach was to try to figure out where the pieces go in each puzzle, and when we find one that didn't fit, set it aside. When we finish we end up with two puzzles that have 400 pieces in them plus some holes. The holes are in different places. But when you "intersect" the two puzzles, can you decide whether or not they are the same picture or not? I can. You want to take ONE of those "extra pieces" and say "this doesn't match any piece in the other box, clearly these are not the same two puzzles. In our comparison, differences did not matter, similarities were the thing we were looking for. IE I don't care if you go stick a pink and blue fake exhaust pipe on the back of your car, it is STILL the same vehicle, it is not new and original.

Can you spell the word assumption?

Let's review Fabien's accusation, then a few quotes of your team in a next post.

Hi Ed,

Yes, this is my conjecture from looking at the Strelka source code which as confirmed by experts is a faithful C
translation of the Rybka binary:

1) Vasik took the Fruit 2.1 public source code [ assumption ]
2) he removed everything that did not hurt Elo rating and could gain some speed [ assumption ]
3) he moved all possible code into static tables or hashable stuff (e.g. pawn shield/storms were moved to hashed
pawn eval) [ assumption ]
4) he converted the board to bitboards, probably by maintaining the two data structures until he finished the
conversion
5) he (probably) manually inlined some other stuff [probably is another word for assumption ]

Examples of 2) are collecting the PV during search, mate-distance pruning and underpromotions (this makes
move generation faster by avoiding having to test for promotion at all). [ assumption ]

The rationale of this process is as follows:
a) speed is the priority; Fruit is slow and simply making it faster is a simple way to get to the top of rating lists [ assumption ]
b) simplify the code as much as possible (move to tables, inline), this will help compiler optimisation too; Fruit was
designed with future development in mind so it had many unnecessary function calls [ assumption ]
c) obfuscation was less of a priority; usually a) and b) automatically bring c) [ assumption ]
d) it's possible to test the engine at anytime to make sure no big mistake was made [ assumption ]

About c), it seems Vasik cared about hiding copied Fruit code like UCI parsing only after Strelka appeared. He
considered a binary was safe enough from investigation. assumption ]

Where is the proof of all these assumptions?

It's like the 9/11 conspiracy theorists, lots of motives, lots of assumptions lots of coincidences, lots of unanswered questions and together they form a story (your puzzle pieces) a large number of people still believe. Especially those with an anti-american sentiment.