OpenChess

Rebel wrote:

hyatt wrote:

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

Chris Whittington wrote:

hyatt wrote:

Rebel wrote:

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

hyatt wrote:

Rebel wrote:

BB+ wrote:

Rebel wrote: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 wrote:

hyatt wrote: 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.

hyatt wrote:

Chris Whittington wrote:

hyatt wrote:

Rebel wrote:

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

Chris Whittington wrote:

hyatt wrote:

Rebel wrote:

BB+ wrote:

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

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

Rebel wrote:Let's review Fabien's accusation ...

Fabien Letouzey wrote:this is my conjecture ...

Rebel wrote: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

Rebel wrote:this is tunnel vision

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

Rebel wrote:What the hell does rule #2 mean?

Rebel (quoting Riis) wrote:To make Rule 2’s absurdity as clear as possible, let me pose some straightforward questions:

Chris Whittington wrote:and a POSITIVE BONUS for being behind the enemy pawns

BB+ wrote:

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

Rebel wrote:Let's review Fabien's accusation ...

Fabien Letouzey wrote: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.

Rebel wrote: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"?

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

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

Rebel wrote:What the hell does rule #2 mean?

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

Rebel (quoting Riis) wrote: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].

Chris Whittington wrote: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.