FIDE Rules on ICGA - Rybka controversy

[Chris Whittington]

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.

IF, note well *IF*, Vas did copy Fruit, then Fabien's fanciful pathway is a possible explanation of how he might have done it.

BUT, note well, *but* this fanciful pathway cannot be put into reverse, and used to state that Vas copied Fruit, for it contains no proof of copying, it is just a fanciful pathway. No more or less any proof than Vas wrote it himself.

Fanciful pathways prove nothing at all.

[Rebel]

About assumptions -

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

Robert Hyatt: The well-known pawn values, used by almost everyone are (a) 100, (b) 128 (deep thought, etc, making it a power of 2 to allow divisions to be replaced by shifts; (c) 256, which makes it again a perfect power of 2. Why he [Vasik Rajlich] chose 3200 is unknown, and I won't speculate very much. But we do KNOW that he obfuscated the depth and node counts (is that a VIG statement or a pure statement of FACT, BTW?). So it is not unreasonable to assume that obfuscation played a part. [ answer ]

Robert Hyatt: Doesn't matter what YOU think. Your reasoning is flawed. The previous version of his program was rated about 800 Elo LOWER. Copying fruit to get to 2700+ makes perfect sense for someone that is willing to violate rules...

Mark Lefler: My understanding was this was on purpose. Fabien wrote the code so it would work from either side, so he just looped over the to sides and correct for black by subtracting. A classic speedup trick is to unroll the loop, and this is what was done in Rybka. Save a little time since the two score do not need to be combined. [ context ] ]

Zach Wegner: (1) - The structure of the material table (at the source code level) isn't certain. It seems likely, based on the disassembly, that the data type is something like this: (2) - The use of unsigned char and bool for phase and lazy eval are quite likely (3) - The flags fields are unclear, though (4) - This compression of two bytes to one byte was most likely done so that....[ page 26 ]

Zach Wegner: All of the endgame and draw recognition logic in Fruit has been replaced by a large material table in Rybka. [ assumption and a false one too. Nothing of Fruit's special endgame knowledge is in Rybka, not in the code not in Rybka's material imbalance table. [ link ]

And so on.

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

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!!

Rybka is NOT "different here". In 1992 Stanback and I were talking at an ACM event and we discussed the idea of evaluating a "rook lift" since we both did it, and in the game one of us was playing, it was an important idea. I have the SAME concept in Crafty today in fact, to detect when the rook is attacking squares close to the king. So don't say "this is new". It might be "new to you" but it is just another idea to the rest of us. As far as a "bonus for being behind enemy pawns" do you have ANY idea what you are talking about? I'd assume no, because this is ALSO not that uncommon in today's programs. You like to call me a dinosaur because I am 67 years old. I'd call you a dinosaur based on brain size, because you think that how YOU might do things is the best way to do them and hardly anybody else was smart enough to come up with that idea. You are wrong.

BTW Rybka has no bonus for getting its rook BEHIND enemy pawns. Only for getting them in front of its own pawns when the enemy has no pawns on the same file. Even that is a bit short-sighted to "some" of us, since getting the rook in front of friendly pawns can help an attack whether the opponent has a pawn on that file or not...

Maybe, one day, you will at LEAST get what Rybka does right somewhere along the way rather than just making junk up...

[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?

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.

I am FAR better at playing chess than Soren is at understanding C, much less ASM.

[hyatt]

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.

Just random, uninformed noise. He is talking about ideas. You have been talking about ideas. Rule 2 does NOT mention the word idea anywhere in it. "algorithmic overlap" is a meaningless term. Everybody uses alpha/beta. Everybody does NOT use the same formulation of alpha/beta. He doesn't get that. But then he is no programmer and is just brandishing words about that he does not understand within the context of computer chess and chess programming. It is pointless to discuss his writing. EVERYTHING is simply non-technical fluff, 90% of it is simply a criticism of the process, of the people, of the rules, absolutely nothing with any "meat" on it regarding actual technical issues such as the evidence produced.

I'm not even going to respond to such nonsense as "what exactly is meant by game playing code." A chess programmer would know the answer to this without any thought whatsoever.

The only valid criticism of rule two was the point FIDE raised. That it did not specify any potential lifetime ban. If we held that investigation today, we could have given him a 15 year ban since that is now in the FIDE cheating rules. Rule two MUST be somewhat vague, otherwise it would take a book to enumerate every possible way to violate it, and then some would complain "but the rule is so damned long, who can read and understand all of that" and we are right back to where we are. Most laws are equally vague. They don't say how many eyewitnesses are required, how many pieces of evidence are required, how much each different type of evidence should be weighted in the analysis, they don't enumerate "weapons" by listing everything that could be used, that would include most every noun in the dictionary for example. It has worked pretty well, and has kept the event reasonably close to what everyone expects. I don't think you could do much better than that.

As far as "statute of limitations" goes, in law there are specific guidelines. For crimes involving murder, in the US there is NO statute of limitations. I saw someone prosecuted a few years ago for a murder committed in the early 60's, for example. But in a private organization, the does NOT have to be a statute of limitations. Unless that organization wants to specify one. As I said, his rambling nonsense looks REALLY bad. Embarrassingly bad.

[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!!

Rybka is NOT "different here". In 1992 Stanback and I were talking at an ACM event and we discussed the idea of evaluating a "rook lift" since we both did it, and in the game one of us was playing, it was an important idea. I have the SAME concept in Crafty today in fact, to detect when the rook is attacking squares close to the king. So don't say "this is new". It might be "new to you" but it is just another idea to the rest of us. As far as a "bonus for being behind enemy pawns" do you have ANY idea what you are talking about? I'd assume no, because this is ALSO not that uncommon in today's programs. You like to call me a dinosaur because I am 67 years old. I'd call you a dinosaur based on brain size, because you think that how YOU might do things is the best way to do them and hardly anybody else was smart enough to come up with that idea. You are wrong.

BTW Rybka has no bonus for getting its rook BEHIND enemy pawns. Only for getting them in front of its own pawns when the enemy has no pawns on the same file. Even that is a bit short-sighted to "some" of us, since getting the rook in front of friendly pawns can help an attack whether the opponent has a pawn on that file or not...

Maybe, one day, you will at LEAST get what Rybka does right somewhere along the way rather than just making junk up...

Yeah right, we all know that anything new and creative that anyone else does has already been done by Bob. hahaha!!

Your para 2 shows that you still do NOT understand what you (erroneously) call Rybka open and half open file code does. Rybka bonuses getting behind the opponent pawn chain in the blocked board example I showed you above. What can I say? You just don't grasp the meaning behind the code. With result you mistake the correlation to Fruit code and falsely claim equivalance. The two programs Rybka and Fruit were doing very different thing here, yet you called them same.

Sorry, Bob, but you were not up to analysing CHESS code created by an International Master, you missed what he was doing. As did Zach (read his comments) and Mark. The creative originality just not spotted by any of you.

Your insults don't help you. I am not "making up junk" as you insult with. I am correctly analysing a real difference and original creative coding that you simply missed. The Vas code here promotes getting behind the enemy pawn chain. The Fruit code here doesn't. This is not copying, this is smart original IM chess coding.

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

I am FAR better at playing chess than Soren is at understanding C, much less ASM.

But you are not good enough at playing chess to understand the Rybka pawn-rook code and see what it is doing. Even when SPELT OUT for you. Because Rybka is written by an IM, an IM who happens also to be a very good programmer, it contains this subtlety that you missed. Have you seen it yet, or are you still denying its existence? Doesn't look good for you.

[BB+]

it becomes Vas verbatim copied Fruit (the real accusation) ...

Let's review Fabien's accusation ...

this is my conjecture ...

There is a difference between a "real accusation" and a "conjecture" -- capiche? Letouzey (effectively) accused Rajlich of copying Fruit with different words, and he conjectured that this was likely done in a fairly explicit manner. Similarly with many of the other programmers that signed the open letter. If you are lazy with the meaning of words, the discussion becomes nonsensical.

I have dwelled among them for 25 years. I know them personally. I know exactly how they think, what they think, also about this case

Who needs evidence? Why not just have the Rebel oracle tell us "exactly how everyone thinks"?

this is tunnel vision

This is looking at the evidence, and seeing how far it goes. The conclusion was that the evidence supports that Rajlich "copied Fruit with different words" (for Rule #2), and is less clear concerning whether Rajlich used copy/paste, re-typed Fruit with the numeric keypad, or made some sort of hybrid with his pre-existing Crafty/Rybka code. And has been stated many many times, the exact method does not matter for most purposes, including ICGA's Rule #2.

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.

As had been indicated any number of times, it is the specific choices that both Fruit and Rybka make to realise said common chess knowledge. As Letouzey said, it's just as much about what Fruit doesn't do in EVAL as what it does. Stockfish and Komodo both implement "chess knowledge", but do so in quite different ways, not a "copy with different words" as with Rybka/Fruit. What is ordinary and common is "an extraction of a couple of ideas", not taking the whole EVAL framework.

What the hell does rule #2 mean?

Each program must be the original work of the entering developers.

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

All of these were effectively answered in my rebuttal. [And probably repeated 100s of times elsewhere].

and a POSITIVE BONUS for being behind the enemy pawns

None of the examined Rybka version give a positive bonus for being behind the enemy pawns per se. They give a bonus for a rook on a open/half-open file when there are no self-pawns in front of the rook. Suppose that you have a White pawn on a7, a White rook on a6, and a Black pawn on a5. By your criterion, the White rook should get a positive bonus, being behind the enemy pawn. In the relevant Rybka versions, it does not receive this, as due to the White pawn on a7 the rook is not on a semi-open file. Furthermore, upon removing the White pawn on a7, the rook receives the same open-file bonus independent of the existence of the Black pawn on a5, again showing that there is no specific condition for "being behind the enemy pawns".

[hyatt]

It was not "new and creative". And it was not "just done by Bob". John was also doing it at the SAME time.

You are certainly making up "new and creative". A rook lift was not uncommon at all. You can even find that mentioned in Hsu's book about deep blue. Along with things like moving a rook to a file that is likely to become open soon, even though it is not seen happening by the search. Might be new to you. Not a new idea to me. And, BTW, a rook on such a "pseudo-half-open file" is NOT as good as a rook on a real open file.

You should stop stating things that are NOT true, such as the "rook behind enemy pawns" that does not exist. Sometimes it would seem that your typing gets way ahead of reality, and you don't stop to check your facts, ever. This is one such place where that would have saved your having to once again backtrack. Just as with Ed's repeatedly claiming the ICGA had posted all of the Vas emails. I only looked on the Wiki and did not see them. I did not think to further check (Mark did however) to see if something had been removed. I just assumed that must have happened since Ed was 100% certain they were posted there. Guess what? They weren't. Again it would be nice to have some actual fact-checking going on in parallel with fingers-pecking-on-the-keyboard. It is bad enough to have to argue about REAL evidence or circumstances, it is much worse to argue about things that don't exist like the rook behind enemy pawns or posts that were never posted, etc...

[Chris Whittington]

it becomes Vas verbatim copied Fruit (the real accusation) ...

Let's review Fabien's accusation ...

this is my conjecture ...

There is a difference between a "real accusation" and a "conjecture" -- capiche? Letouzey (effectively) accused Rajlich of copying Fruit with different words, and he conjectured that this was likely done in a fairly explicit manner. Similarly with many of the other programmers that signed the open letter. If you are lazy with the meaning of words, the discussion becomes nonsensical.

I have dwelled among them for 25 years. I know them personally. I know exactly how they think, what they think, also about this case

Who needs evidence? Why not just have the Rebel oracle tell us "exactly how everyone thinks"?

this is tunnel vision

This is looking at the evidence, and seeing how far it goes. The conclusion was that the evidence supports that Rajlich "copied Fruit with different words" (for Rule #2), and is less clear concerning whether Rajlich used copy/paste, re-typed Fruit with the numeric keypad, or made some sort of hybrid with his pre-existing Crafty/Rybka code. And has been stated many many times, the exact method does not matter for most purposes, including ICGA's Rule #2.

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.

As had been indicated any number of times, it is the specific choices that both Fruit and Rybka make to realise said common chess knowledge. As Letouzey said, it's just as much about what Fruit doesn't do in EVAL as what it does. Stockfish and Komodo both implement "chess knowledge", but do so in quite different ways, not a "copy with different words" as with Rybka/Fruit. What is ordinary and common is "an extraction of a couple of ideas", not taking the whole EVAL framework.

What the hell does rule #2 mean?

Each program must be the original work of the entering developers.

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

All of these were effectively answered in my rebuttal. [And probably repeated 100s of times elsewhere].

and a POSITIVE BONUS for being behind the enemy pawns

None of the examined Rybka version give a positive bonus for being behind the enemy pawns per se. They give a bonus for a rook on a open/half-open file when there are no self-pawns in front of the rook. Suppose that you have a White pawn on a7, a White rook on a6, and a Black pawn on a5. But your criterion, the White rook should get a positive bonus, being behind the enemy pawn. In the relevant Rybka versions, it does not receive this, as due to the White pawn on a7 the rook is not on a semi-open file.

You insist on calling this situation half open/open file, but it isn't is it? The chess definition half open or open simply does not apply to a own pawn ALSO on file. Why do you insist on the false definition? Because you are unconsciously biased to force Rybka code into parallels with Fruit structures, even when that steucture does NOT exist in Rybka.

OK, your example. you know perfectly well that chess board pattern recognition as implemented by programmers are general purpose. Sure you can disrupt the tendency for the algorithm to put its rook on a specific file behind the enemy pawn chain by inserting a friendly pawn on a very advanced position on that same file. But what you are really trying to disrupt with this quite fanciful positioning (remember, we are discussing heavily blocked pawn frontages, with an open file penetration) is the argument that Rybka has a creative and original algorithm/pattern recognition, which is strongly superior. I''m shocked, Mark, that you stoop to this.