Wisdom is knowing how

   little we know -- Socrates

About Company

Started in 1980, retired in 2004 REBEL was baptized into ProDeo, latin for gratis according to Dutch tradition.

Other Information

    Rybka-ICGA fiasco

 

 

    External links

 

 

 

 

  • TOPICS

 

 

 

 

  • The alleged PST obfuscation

 

  • The allegedPawn value obfuscation, Fruit=100 vs Rybka=3200 (3999)

 

 

 

 

     

      


    •  

       

      • HOME
    •  

      After 3 months of intensive research it's my final conclusion the accusers who investigated the Rybka chess program researched an original program doing all the same things other (good) programs also do. Rybka is an original chess program, the ICGA verdict and ban are uncalled for.

       

      Rybka Quick Guide




      INTRODUCTION

      This page is dedicated to my fellow chess programmers who have an interest in an alternative view of the 2011 historic event that led to the ICGA investigation, verdict and ban of Rybka which is all about the ICGA rule 2 which states:

      Each program must be the original work of the entering developers. Programming teams whose code is derived from or including game-playing code written by others must name all other authors, or the source of such code, in their submission details.

       

      What went wrong ?


      Simply put: the lack of a decent opposition during a 5-6 year of anti-Rybka campaign in several computer chess fora.

       

      By hearing 5-6 year long: Vas started with Fruit because he is a thief Vas eventually became the thief because he started with Fruit. Classic circular reasoning, the conclusion is the premise and the premise is the conclusion. 

      Keep this in mind reading the rest of this page in which I will try to demonstrate that Rybka 1.0 is fundamental dissimilar than Fruit 2.1 by listing all the differences (currently 30 of which 20 in EVAL) between the 2 engines I discovered during the last months and in the process address other counter evidences.

      While reading realize also the relative short period Vas had to accomplish all that, just 5½ months, getting familiar with the Fruit sources, mailbox to bitboard conversion, testing, tuning etc. adding 150 elo in the process and how unlikely it becomes Vas took the Fruit 2.1 source code as a base for Rybka.

       

      And furhermore:

       

      1. If you are 150 elo above all the rest you have an original program.
          
      2. If you further add another 250 elo you are unique.
          
      3. That countless cloners have been caught almost instantly by leaving obvious traces and contrary to Rybka it took 4-5 years all the way up to a painful process of reverse eniginering an executable. The latter should have told the Rybka investigators something.
           
          
      4. That the Strelka sources (half fruit, half rybka) instead of a help also had its dangers falling for fictional code not in Rybka and tunnel visions which in fact happened and we would like to demonstrate.


      Basically that there is no proof of copied code, not even the notorious 0.0 case one the strongest indicators for many chess programmers to speak the guilty verdict.

       

      That today after a decent counter investigation by a group of dissentient chess programmers and other experts an appeal now with a PREPARED OPPOSITION the ICGA accusations and verdict will fall apart.

       

      I know many of my colleagues personally and I consider them honest people willing to have a good look at the counter evidence presented on these pages, mainly this page and [ Rybka Quick Guide  [ Rybka fruitification ]  [ Rybka 1.0 source code ]  [ Semantics ] and that the gross injustice done to Vasik will be undone.

       

       


      Chapter 1, The Accusation

      Here anno 2009 Zach Wegner a competitor of Rybka is accusing programmer Vasik Rajlich author of Rybka of plagiarism the work of Fabien Letouzey author of Fruit.

      Zach Wegner: EVERY single evaluation term in Rybka 1, except for the material imbalance table, appears in Fruit. If everyone wants to consider that "original", then computer chess is really dead.

       

      Refutation:

      1. Already in the 80's my chess program REBEL had more chess knowledge inside than FRUIT. With the Zach Wegner logic in mind I could accuse the authors of FRUIT, RYBKA, FRITZ etc. etc. of having plagiarized my work. However that would be nonsense as there is no copyright or whatsoever on public general (chess or whatever) knowledge.
          
      2. At the time I wrote REBEL (early 80's) I have read about every instructive chess book and implemented the chess knowledge found in those books into REBEL which is a perfectly legal thing to do.
          
      3. That the accusers failed to realize that something happened in the late 90's : INTERNET. Source code all over, resulting in an explosion of knowledge. It's perfectly legal to study source code that is freely downloadable on the Internet, read them like a chess book (as I did) and take chess knowledge ideas and FRUIT 2.1 falls into that category.  
          
      4. That therefore it's completely irrelevant to compare one chess program with another on the overlap of chess knowledge such as the presented evidence by Mark Watkins which was used in the ICGA trial against Vasik Rajlich. Chess knowledge is not copyrightable. And available everywhere.
           
          
      5. What the Rybka investigators needed to proof is evidence that Vasik Rajlich took the FRUIT source code as a base, modified it and called it his own.
          
      6. And that is something of a total different magnitude. And they failed to make a case provided you are ready to invest some months of your spare time. These pages are meant to shorten that process.

       

       


       

       

      Chapter 2, the alleged obfuscations in Rybka to hide its FRUIT origin.


      Robert Hyatt: (1) Obfuscation. Vas intentionally misled everyone by doing the following: (a) reporting a false depth; (b) reporting false node counts; (c) reporting incomplete PVs to hide (a) most likely.

       

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

       

      I lost track counting the number of obfuscation allegations made in computer chess fora when the RYBKA=FRUIT anti-Rybka campaign started in 2006. The 2 above examples from 2 key-accusers should suffice for the sake of the length of this page.

      All of this to proof RYBKA being a clone of FRUIT. Looking at those allegations a bit more critical all of them are perfectly explainable and don't fit the RYBKA=FRUIT accusation at all. I now would like to address them point by point. 


       


        

      Chapter 2.1 - The alleged PST obfuscation in Rybka to hide its FRUIT origin.


      Zach Wegner: We have found that, looking at the PST values of Fruit and Rybka, that Rybka's PSTs can be calculated using Fruit's code with a minimum of changes. The only differences are the various weights (the constants found near the top of pst.cpp in Fruit) and the bonuses for center pawns. Because of Fruit's unique PST initialization code, the origin of Rybka's PSTs in Fruit is clear.

       

      To understand what Zach Wegner is saying here is the accusation that Vasik Rajlich for reasons of deliberate obfuscation "copied" Fruit's formula based generated PST tables, calculated the results, converted the output to readable C-data and imported the C-data into Rybka as source code. And that on top of that for advanced further obfuscation all the cells of the PST's were multiplied with 32.

      My first objection to this kind of thinking is that Vasik Rajlich an unknown name in computer chess back in 2005, that brilliant Vasik already realized in 2005 he would become so famous that he foresaw the scenario that his program would be disassembled, reverse engineered by Osipov (Strelka) and yet brilliant Vasik was stupid enough to call Strelka his own back in 2007, oil to the fire for the anti-Rybka camp to double their energy.

      This kind of scenarios makes no sense and Occam's razor applies. Most chess programs have build-in PST's, either hand-typed or generated and Rybka is no exception. It's far more logical.

       

      My second objection becomes clear if we simply visiualize the Fruit and Rybka PST's and notice there is only one match, the rook. And as profesor Miguel Ballicora clearly demonstrated that's not uncommon in chess programs, he found PST matches in Crafty and Stockfish. [ 1 ] [ 2 ] [ 3 ] [ 4 ]


      There is more to say about the PST allegation and is addressed elsewhere by the work of Professor Miguel Ballicora. But the technical details fall outside the scope of this page which is to explain the obfuscation allegations can be easily refuted.



      Chapter 2.2 - The alleged FRUIT (100) vs Rybka (3200-3399)
       obfuscation to hide its FRUIT origin.


       

      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.

       

      The facts first:

       

      1. 1. The FRUIT base value of a pawn is 100. Very normal in chess programming following the known beginner rule of: 1/3/3/5/9.
          
      2. The RYBKA base value of a pawn is 3200. An extreme high value very uncommon and also prone to make all kind of calculation errors.
          
      3. Furthermore the score in the evaluation is multiplied with 3399 and at the end of the evaluation dived by 32 to eventually match the Fruit score (100). 
           
        This highly circuitous process (100 -> 3200 -> 3399 -> /32) looks suspicious and feeds the thought of the PST's obfuscations (100 * 32 = 3200) as already addressed above and it was a hard nut to crack.
          
      4. And yet all of this can be convincingly explained in a different way as 3200/32 is a search improvement and 3399 is a tuning parameter.
          
      5. The goal of 3200/32 -> more equal scores but better rounded -> more beta-cutoffs -> (somewhat) faster search.
          
      6. 2. The goal of 3399 just a tuning parameter as for instance found in my own ancient program.
          
        [Attractiveness = 101]

        A comparable value (3399 vs 3200) would be 106.

        It's this kind of impressive original findings (3200) why Vasik Rajlich could dominate the computer chess world for the last 5 years, the man simply is a genius, an IM (International Master) and graduated MIT student.

        No obfuscation present, just an improvement.





      Chapter 2.3 - Known RYBKA depth and nodes obfuscation.


      Robert Hyatt:(1) Obfuscation. Vas intentionally misled everyone by doing the following: (a) reporting a false depth; (b) reporting false node counts; (c) reporting incomplete PVs to hide (a) most likely.

       

      So why did Vasik do it? Why did Rybka 1.0 displayed a lesser depth (2 plies) then it was actually was doing? It certainly CAN NOT for reasons of obfuscation hiding the alleged FRUIT origin BECAUSE by doing so the RYBKA depth almost equals the FRUIT depth!! So there goes another obfuscation myth that should proof the RYBKA / FRUIT relationship.

      The more logical reason is to hide the real reason for Rybka's success to his opponents -> a deeper search. A 2 plies deeper search than your direct competitors is a lot, usually good for some 60-80 elo points. The same applies to the nodes obfuscation, hide the secret for your success.

      As for the ethics, that's debatable of course but not related to subject of plagiarism FRUIT.




      Chapter 2.4 - The smoking gun that should be there but wasn't



      Ed Schroder: Sometimes the best evidence is the evidence that unburdens a suspect.... see the link above.

       

      Provided you have read the above link and what it is trying to say (and this is real programmer stuff) then consider:

      1. In a situation that you as a programmer have to check 20-30 items such as keyboard input (or commands from the GUI such as UCI) with no demanding order then what do you pick first? It will depend from programmer to programmer as the nature is completely random. As such taking UCI as an example every programmer that does not "copy" will leave his own signature in the ORDER of programming UCI. The same applies for EVAL (evaluation).
          
             
      2. As such the order of handling things in a random process can be seen as evidence for copying. The opposite is also true, the lack of an equal or very similar order should count as unburden evidence for copying.
          
      3. The facts: the order of EVAL in FRUIT is not equal nor similar than the order of EVAL in RYBKA.
          
      4. The order of UCI in FRUIT vs the order in RYBKA is also totally different. It's addressed on an separate page.

       

      My posting was not very welcome by the leaders of the anti-Rybka camp, see the follow-up's. 

      Robert Hyatt: That is, without a doubt, one of the strangest posts I have ever seen.
      Zach Wegner: With this post, I am now unable to take you seriously at all. Sorry.

      This is odd because Zach Wegner in his document uses that same exact ingredient (order in EVAL) as evidence for copying.

      Zach Wegner: Also, it should be noted that each evaluation uses the exact same terms in the exact same order: doubled, isolated, backwards, passers, candidates.

       

      The logic escapes me here, calling 5 continuous EVAL terms as evidence for copying, yet at the same time denying the lack of order for the whole EVAL as unburden evidence. It just doesn't fit the accusation RYBKA started its life as FRUIT by copying.

      And so we are back at obfuscation square one, Vasik in 2005 already foresaw he became so famous some people would disassemble his program looking for Fruit traces and therefore Vasik deliberately decided to obfuscate the order in EVAL. This is a bizarre scenario.

       

      Every open chess source I have checked has a complete different order in EVAL because of its random nature, my own included and as one might expect FRUIT and RYBKA are no exceptions. They all have a different order in EVAL as it should.

      It's far more likely Vasik Rajlich simply spoke the truth in his email to David Levy during the ICGA investigation period.

       

      Hi David,

      I'm not really sure what to say. The Rybka source code is original. I used lots of ideas from Fruit, as I have mentioned many times. Both Fruit and Rybka also use all sorts of common computer chess ideas.

      Aside from that, this document is horribly bogus. All that "Rybka code" isn't Rybka code, it's just someone's imagination.

      Best regards,

      Vas

       

      After 3 months of intensive research I fully agree. Rybka is an original chess program doing all the same things other (good) programs do also.




      Chapter 3 - The suspect 600-800 elo jump.


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

       

      This was the very first question asked right after the release of Rybka 1.0 (december 2005) in the computer chess fora. How is it possible that a no-name in computer chess with a weak program (estimated elo 2000-2200 max) can make a 600-800 elo jump and top all rating lists out of the blue? Usually the elo performance is a gradual process with steps of 50-100 elo a year, that is, if you are good.

      I was used to think that way also until I realized a couple of things:

      1. That if you are able to add 400 elo to an 2800 elo program (Rybka 1.0), then yes you can.
          
      2. That we are not any longer in the dark 70's and 80's, something happened in the 90's : INTERNET. Source code all over, an explosion of knowledge. Modern programmers don't have to reinvent the wheel, modern chess programmers with ease read the free sources as the rest of world reads his news paper and then know what to do. Notable stated by Vasik himself in the README file that came with the Rybka 1.0 release, see the SPECIAL THANKS section at the first page.
          
      3. Best example: FRUIT itself. Practically also coming out of nowhere.

        

      Another example would be Christophe Theron and his Chess Tiger also coming out of nothing and topping the SSDF rating list.

      Other examples: Ruffian and Zappa

      Meaning, it's not that unusual.




      Chapter 4 - The denial of valid points


      Some critical words then to the investigators (Mark Watkins and Zach Wegner) and the evidence against RYBKA they provided in the 3 documents after having reverse engineered the Rybka 1.0 executable, a process of hard work that took years to finish following their own words. Is it that hard? Yes it is. I exclusively have programmed my chess programs during 25 years in assembler and so I do know a couple of things. Reverse engineering (RE) is something else as normal programming, you can be a programmer but that doesn't make you a RE-programmer.

      1. That because of that there has to be some kind of basic trust and that I was ready to accept the creative work of years by Zach Wegner and Mark Watkins because it's hard to deny quality when you see it;  
          
      2. That as such I accepted their authority as RE experts in the RYBKA=FRUIT matter;
          
      3. That this BASIC TRUST fell apart when Zach Wegner and Mark Watkins started to deny several valid points made by the opposition.

         

      RE evidence is a thin ice experience for both parties involved, the experts (Mark Watkins and Zach Wegner) and their critical audience (the chess programmers). However if an expert becomes the subject himself instead of his work the benefit of the doubt is gone. Evidence of the opposition was denied in the following cases:

       

      1. Denying the unburden PST evidence, CSTAL programmer Chris Whittington for addressing the issue and Professor Miguel Ballicora for providing alternative explanations as stated elsewhere.
          
      2. Denying the unburden UCI and EVAL order evidence as stated in Chapter 2.4
          
      3. The denial of the so-called "fruitification case" case, also here.



      Chapter 5 - The SETJMP case, see also chapter 4 of Mark Watkins document.


      Marcel van Kervinck:  But back to the point: My program uses setjmp/longjmp and I don't agree that it is a sign of copying chess playing code. I got the idea from K&R, not from Fruit. I wasn't aware that Fruit was using it as well for the same purpose.

       

      A minor case but worthy enough to say a few words about it.

      1. The use of setjmp in a program is awful programming, you won't get your certificate if you try that during your first programming class. And yet it can be very handy if you know what you are doing, I have used it in the past when space was limited on the good old 16 Kb (16,000 bytes) 6502 days, Chris Whittington has used it in the past, Marcel van Kervinck apparently still uses it. In general SETJMP is very handy to jump out a recursive loop (common in chess programming) what seems to be the case at hand.

      2. The choice of "depth=4" in both FRUIT and RYBKA is a sane choice. I have used "depth=3" myself for a very long time but when hardware became faster and faster I raised the value to "depth=5". It's just a minor improvement as it statistically guarantees a better move to ponder.




      Chapter 6 - The notorious 0.0 case.


       

      It's about time-control and the accusation that Vasik "copied" that from FRUIT.

      In a nutshell:

      FRUIT's time control is fully FLOAT based;
      RYBKA's time control is fully INT based.

      And yet in RYBKA's time-control a FLOAT value is found -> 0.0 which is odd indeed.

       

      The instruction in question:

       

      if (movetime >= 0.0) {          // see protocol.cpp (line 377)

       

      The accusation is that Vasik "copied" the FRUIT time-control, converted FLOAT to INT to obfuscate (there is that pesky word again) the FRUIT origins. But in the process Vasik overlooked one instruction, the 0.0 and so a trace of copying was left.

      Its rebuttal:

       

      First of all the Rybka investigators made a mistake, the decompile does not state:

       

      if (movetime >= 0.0)

       

      but

       

      if (movetime > 0.0)

       

      Technical explanation at the Time Control page.

       

      Secondly, compile the following code with any of the MS compilers.

       

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


      It will produce the same code as 0.0

       

      or compile

       

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


      It will produce the same code as 0.0

       

      Meaning the 0.0 accusation falls apart, what was strong evidence for 4-5 years is now minimized to overlooking a dot typo.

       

      Either missing 1 pixel on a 1920 - 1080 screen or the suggestion that Vas while obusfacting the Fruit

      if (movetime >= 0.0) instruction he first removed the "=" chararcter but then forgot to remove the float trace which according to the acccusation was the goal in the first place, hide the Fruit (FLOAT) origins.

       

      Furthermore read the separate page about Time Control and notice that Rybka has 2 bugs in that tiny block of code. Check it with Rybka 1.0, set the time control to "5 seconds fixed time" and notice Rybka 1.0 doesn't move after 5 seconds. Fruit does. Then pitch the 2 rivals Rybka 1.0 and Fruit 2.1 at a time control of 1min/all and notice that Rybka 1.0 loses 20% of its games on time forfeit. Fruit none.

       

      Copy Fruit and then introduce 2 bugs in 10 lines of code is hardly a valid accusation.

       

      In december 2011 I asked Vas on the 0.0 issue and he said:

       

      There isn't much I can help with here. I don't know where the 0.0 came from. It's definitely weird/wrong.

      Rybka was UCI from the beginning, even back when everybody was using WinBoard. I would say that every two to three years I do a big cleanup of this code. This might take a few hours, and then I won't touch it until the next time. My first UCI parser actually used inheritance, I was extending UCI to do some testing, but that was gone even before Rybka 1.

       

      Best regards,
      Vas

       



      Chapter 7 - Principal differences between Rybka and Fruit
      Introduction


      When confronted with the fruitification case Mark Watkins camouflaged the problem by saying at Open Chess:

      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.

       

      And so I (with the help of some other chess programmers) like to present a list with fundamental, principal and minor differences between Rybka and Fruit which by the same standard (as a whole) should be judged.

      We begin with the Time Control issue. Rick Fadden in 2008 decompiled Rybka's UCI time control code and compared with Fruit's UCI time control it was generally assumed VR copied. As it seems the provided information was convincing enough for Rybka investigator Mark Watkins to include it in his document that served as one of the main pillars during the ICGA investigation.

       

      We decided to research the whole decompilation, found 3 errors and like to report on a separate page for length reasons.

       



      Chapter 7.1 - Lazy evaluation (also known as LE)


      LE is not in Fruit but present in Rybka.

      It's usually good for some 20-30-50 elo points improvement depending per program.

      Rating: fundamental
      .




      Chapter 7.2 - Different futility pruning


      Mark Watkins chapter B.1. : The principal new idea in Rybka 1.0 Beta seems to me to be the loosening of the stringent cutoff values for futility previously used in the AEL pruning of Heinz. These add up to about a 75-100 Elo improvement on a 32-bit machine, comparable to the amount that Fruit itself gained over the second half of 2005.


      See also Razoring in Strelka.

      Rating: fundamental.



      Chapter 7.3 - The absence of minor promotions in Rybka


      The absence of minor promotions in Rybka is odd, it could be a bug in present code or that there is nothing in Rybka at all. Fruit however does support minor promotions.

      It's a pity the investigators don't mention this issue as unburden evidence or burden evidence by looking at the similarity between Rybka and Fruit.

      Rating: minor. 



      Chapter 7.4 - The absence of evaluation arrays in Fruit


      Basically Fruit has only one evaluation array, King Safety.

       

      Rybka has many.

       

      FRUIT: static const int KingAttackWeight[16] = 
       { 0, 0, 128, 192, 224, 240, 248, 252, 254, 255, 256, 256 ,256, 256, 256, 256, }
       
      RYBKA - from Zach Wegner's document: 
       
      const int shelter_value[5] = { 1121, 0, 214, 749, 915 } 
      const int storm_value[5] = { 0, 0, 2334, 653, 310 }; 
      const int storm_value[5] = { 0, 0, 2334, 653, 310 }; 
      int PassedOpening[8] = { 0, 0, 0, 489, 1450,2900, 4821, 4821 }; 
      int PassedEndgame[8] = { 146, 146, 146, 336,709, 1273, 2020, 2020 }; 
      int PassedUnblockedOwn[8] = { 0, 0, 0, 26, 78,157, 262, 262 }; 
      int PassedUnblockedOpp[8] = { 0, 0, 0, 133,394, 788, 1311, 1311 }; 
      int PassedFree[8] = { 0, 0, 0, 101, 300, 601,1000, 1000 }; 
      int PassedAttDistance[8] = { 0, 0, 0, 66, 195,391, 650, 650 }; 
      int PassedDefDistance[8] = { 0, 0, 0, 131, 389,779, 1295, 1295 } 
      int CandidateOpening[8] = { 0, 0, 0, 382, 1131,2263, 3763, 3763 }; 
      int CandidateEndgame[8] = { 18, 18, 18, 181, 501, 985, 1626, 1626 }; 
       
      Notes:
       
      1. Of course there could be many more Rybka arrays not present in the documents but since that falls outside the scoop of their goal to proof Rybka=Fruit and limit themselves to the main points and for reasons of volume reduction also it is acceptable.
          
      2. Nevertheless it's somewhat odd Rybka's king safety (KingAttackWeigh) table is not listed, instead Zach Wegner states: Fruit keeps a separate factor KingAttackOpening that is also multiplied in. Rybka effectively keeps this factor inside the constant KingAttackUnit table. This should be seen as simply a speed optimization.

       

      Nevertheless, different is different. And it surely does produce different code.

      Rating: principal.




      Chapter 7.5 - The material table


      Zach Wegner: The material tables in Rybka were one of the more interesting features introduced. Their implementation was a new way to evaluate material imbalances. The indexing and evaluations in the table seem to be unique, but there are some very interesting similarities in the information stored in the table with Fruit.

       

      This is one of the worst examples in Zach Wegner's document, another example of fruitification Rybka to make it look like Fruit.

      First of all Fruit has NOT a material table such as Rybka, Fruit has a hash-table that is maintained during search whereas Rybka has a fixed large pre-computed material imbalance table inside the executable with a size of over 1MB.

      Rybka has almost all things different compared to Fruit but in the Wegner's document it is almost identical. Read carefully further:

       

      Zach Wegner: There are a set of flags in Fruit that are not in Rybka. All of these (DrawNodeFlag, MatRookPawnFlag, MatBishopFlag, and MatKnightFlag) are not included in Rybka because it does not have any separate endgame knowledge, which is the purpose of all of these flags in Fruit. Rybka has all other flags that are in Fruit, and also an additional lazy evaluation flag. Fruit does not have lazy evaluation, so there is no flag in it.

       

      From Fruit 2.1, material.h: 
       
      const int DrawNodeFlag = 1 << 0; 
      const int DrawBishopFlag = 1 << 1; 
      const int MatRookPawnFlag = 1 << 0; 
      const int MatBishopFlag = 1 << 1; 
      const int MatKnightFlag = 1 << 2; 
      const int MatKingFlag = 1 << 3; 
       
      
      

      Meaning, Fruit has six flags. Four of them (as Zach admits) are not in Rybka. But then Zach continues Rybka has all other flags that are in Fruit. 6-4=2 means all Zach? And further down in the Zach document we read looking at the left-to-right comparison that the "MatKingFlag" implementation is similar (but different), and that the "DrawBishopFlag" implementation is (said to be) the same but its usage is completely different in Rybka.


      BTW, note that Mark Watkins is a lot more careful in his document about the material imbalance table.

      Judgment: a brand new idea in computer chess.

      Rating: fundamental.




      Chapter 7.6 - Rybka's pre-calculated "quad" function


      Another case of Reversal of the burden of proof as we have seen before and will see more in this section.

      The Fruit "quad" function calculates a value based on the rank of a passed pawn in a very unusual way, spilling loads of valuable processor time while there is no need because it can be done in just one instruction, via a PST or rank-based table, as Rybka does, as any other program does.

      Fruit's "quad" is not in Rybka and neither in any other chess program on this Planet and yet it is used as evidence against Rybka as a speed improvement. Now consider for a moment Fruit's "quad" function was found in Rybka what would change? Nothing, Vasik still is guilty plagiarizing Fruit. A typical -/- situation. Vasik always loses.

      That's bad science.

      Rating: principal




      Chapter 7.7 - Rybka vs Fruit evaluation techniques


      Another case of Reversal of the burden of proof.

      Both Fruit and Rybka evaluate via 2 variables, "opening" and "endgame".

      I often heard the accusation, that's proof Vasik plagiarized Fruit. And probably driven by Zach's document:

      Zach Wegner (Section Phase) : One of the more unique aspects of the Fruit evaluation is that it calculates two different scores, for opening and endgame, and interpolates between the two based on the phase of the game (which is calculated from the material left on the board). This was quite uncommon when Fruit first appeared (if it was used elsewhere at all)


      Mark Watkins Section D.2.2 : Phalanx XXII computes middlegame and endgame scores,

       

      Obviously Phalanx XXII was years before Fruit and Rybka entered the computer chess arena. Check out the variables "midresult" and "endresult". So that's another myth solved.

      PART II

      Fruit evaluates different than Rybka. Fruit (unusually) evaluates in 2 steps, Rybka (normally) directly adding to the sore. And example:

      op[me] += mob * BishopMobOpening; 
      eg[me] += mob * BishopMobEndgame; 
       
      And that they later are merged with the 2 real scores -> opening and endgame. 
       
      // update 
       
      *opening += ((op[White] - op[Black]) * PieceActivityWeight) / 256; 
      *endgame += ((eg[White] - eg[Black]) * PieceActivityWeight) / 256; 
       
      WHILE Rybka directly adds to opening and endgame. 
       
      401b67: 81 c6 cb 03 00 00 add esi,0x3cb // 971 (1035 - 64) 
      401b6d: 81 c7 ac 00 00 00 add edi,0xac // 172 (428 - 256) 
       
      
      

      And there are many more examples available in the Fruit evaluation of this 2 step evaluation, the above just being one example.

      When this issue was presented 2 key people of the ICGA in charge for the ICGA Panel that condemned Vas guilty responded as
      as follows:

      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.

       

      Robert Hyatt: Very possible. The primary point, however, is that we have a very small group (2 actually) that want to claim dishonesty, misrepresentation, and a host of other things, since they have, apparently, given up on discrediting the evidence itself. So now we are entering state III of this process (the first was denial, the second was the evidence is flawed) where the people involved are simply trying to deceive everyone by pointing out flaws that do not exist and which do not make any sense whatsoever.

       

      Whatever Vasik does he still is guilty plagiarizing Fruit whether the unusual Fruit code is in Rybka or not.

      The words of a wise man comes to mind:

      Albert Einstein: If the facts don't fit the theory, change the facts.

       

      And the facts are, Rybka evaluates different than Fruit.

      Rating: principal


       



      Chapter 7.8 - The lack of history reductions



      Fruit uses the technique of History reductions to reduce the size of the tree. The history tables as used in Fruit are absent in Rybka.

      Mark Watkins: Rybka 1.0 Beta also does not have the history-based reductions made prominent by Fruit 2.1, but rather a more vanilla LMR approach that considers only the location in the move list.

       

      Anno 2005 with the Fruit 2.1 sources released in half of June, Rybka 1.0 released (only) 5.5 months later that's quite a remarkable information Vasik moved from History Reductions to LMR long before Tord Romstad author of Stockfish made the idea popular.

      Vasik Rajlich: Actually, I talked to Stefan about it and yes, he was using LMR in almost exactly the modern way already with Shredder 7. This means re-searches, exceptions for late-move captures and other special moves, etc.

      In my view, Tord clearly deserves the main credit for LMR. Fabien probably deserves the #2 spot, since Fruit is what really showed beyond any doubt that this works.

      Vas.

       

      Judgment: different.

      Rating: interesting.




      Chapter 7.9 - Lazy eval flag in the material imbalance table


      Another brand new idea to speed up the search.

      Judgment: different.

      Rating: minor.




      Chapter 7.10 - Mailbox vs Bitboard

       

      Mailbox -old paradigm of evaluation.
      Bitboard - new modern way of evaluation
       

       
      
      

      Rating: fundamental.

      Somehow the Rybka investigators were able to undermine Rybka's MAIN unburden evidence (a bit-board engine) into a disadvantage that greatly worked against Vas. If there is a difference between Fruit and Rybka blame it on the bit-boards and the difference magically disappears.

       

      An example we find in chaper 7.13 discussing Mobility.

       



      Chapter 7.11 - Minor differences in evaluation


      Trapped Bishop
      Fruit WBa7 penalty Rybka WBa7 penalty 
      Fruit WBa6 penalty /2 Rybka WBa6 FULL penalty
       
      
      

      Rook

      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.

       

      Bishop Pair

      FRUIT:    static const int BishopPairOpening = 50;

      RYBKA:    Missing in Zach's document how Rybka handles the Bishop Pair.

       

      Double Pawns

      
      
      Doubled Pawns in Rybka also has a score of zero for doubled pawns in the 
      opening while Fruit doesn't. 
       
      Fruit
      static const int DoubledOpening = 10; 
      static const int DoubledEndgame = 20; 
       
      Rybka 
      static const int DoubledEndgame = 20; 
       
      King Saftey
      Both Fruit and Rybka evaluate a rook on an open file directed at the 
      opponent king which is a pretty standard evaluation term. When for 
      example the black king is on G8 then:
       
      Fruit will add a bonus for a rook on an open F-G-H file while Rybka will
      only add a bonus for a rook on the same file.
       
      Backward pawn evaluation
      Both Fruit and Rybka (as any other good program) evaluate backward pawns.
       
      Rybka vs Fruit
       
      1. Fruit's backward pawn is different, quite unique I must say, as it has 
       code for second ranked pawns that can advance 2 squares. Rybka has not,
       just a quick and dirty evaluation.

       

      2. Semantic structure different. Rybka evaluates directly, not afterwards as

      Fruit does, no variable maintenance also.

       
       
       
      
      

      Rating: all minor.

       

      Nevertheless since the claim of the Rybka investigators is that Rybka's evaluation is virtual equal to Fruit's all these differences (whether big or small) don't support the accusation when they grow in volume.



      Chapter 7.12 - Endgame differences

       

      Last chapter listing evaluation differences we found so far, the end game features in both chess engines.

       

      We compared some fundamental endgame chess knowledge and there seems to be a world of differences between Fruit and Rybka.

       

       

      Fruit has knowledge in KPKR endings when the game is a draw, Rybka 1.0 has none.

       

      Fruit can mate the KBNK, Rybka 1.0 draws after 50 moves.

       

      Fruit knows that KPKQ with a white pawn on the 7th rank is a draw and when not. Rybka 1.0 has no clue.

       

      Fruit knows this is a draw, Rybka 1.0 does not.

       

      Fruit knows 1..Ke6 ensures the draw, Rybka 1.0 does not.

       

      Fruit knows the position is a draw, Rybka has no knowledge, not even with one black rook pawn.

       

       

      From a programmer point of view one might argue this kind of chess knowledge is not needed because the table bases cover this, from the Rybka investigators one might expect to list this kind of unburden differences that don't support the thought Rybka started its life as Fruit.

       

      Instead we would like to point out that if the endgame knowledge would have been found in Rybka it likely would have been also found the ICGA documents as proof for their claim that: Simply put, Rybka's evaluation is virtually identical to Fruit's.

       

      Your Mileage May Vary but in our opinion logic requires to avoid typical -/- situations the accused is always guilty.

       



      Chapter 7.13 - Common sense

       

      Zach Wegner - The mobility calculations of Fruit and Rybka seem different, but Rybka's turns out to be a simple bitboard translation of Fruit's.

       

      The bit-board excuse again.

       

      Somehow the Rybka investigators were able to undermine Rybka's MAIN unburden evidence (a bit-board engine) into a disadvantage that greatly worked against Vas. If there is a difference between Fruit and Rybka blame it on the bit-boards and the difference magically disappears.

       

      When we look at Fruit's and Rybka's code in question we get:

       

      FRUIT :

       

               case Bishop64:

                  // mobility

                  mob = -BishopUnit;

                  for (to = from-17; capture=board->square[to], THROUGH(capture); to -= 17) mob += MobMove;
                  mob += unit[capture];

                  for (to = from-15; capture=board->square[to], THROUGH(capture); to -= 15) mob += MobMove;
                  mob += unit[capture];

                  for (to = from+15; capture=board->square[to], THROUGH(capture); to += 15) mob += MobMove;
                  mob += unit[capture];

                  for (to = from+17; capture=board->square[to], THROUGH(capture); to += 17) mob += MobMove;
                  mob += unit[capture];

      RYBKA:

                  mob = popcnt(attacks & ~own_pieces);


      Common sense states that when you write code 10-20 times faster, pack 4 expensive loops into 1 instruction you are the better engineer. Furthermore there is no copyright on chess knowledge, no copyright on commonly used concepts such as mobility especially not when it's explained in detail on the Wiki chess pages.

       



      Chapter 8 - plagiarism

      Andrew Dalke is a software specialist who contacted me about the ICGA-Rybka case.  He discovered an error in Watkins document nobody until then noticed.
       
      Andrew wrote me his findings.
       
      Indeed, their reports show that there are extensive differences between the two implementations, like Rybka's use of a bitboard. They argue that those changes are mechanical transformations of the Fruit implementation, and therefore not a new implementation of the uncopywriteable algorithms expressed in Fruit but a derivative work in the copyright sense. Lexmark International, Inc. v. Static Control Components, Inc. accepts that conversion of a function to lookup table, or rearranging terms in an expression are not by themselves original acts. However, the transformations in Rybka go well beyond mechanical changes at the call graph level.

      They have instead gone up to a higher level of abstraction shown that the code in Fruit, with different input parameters than the Fruit defaults, can generate numbers which after post-processing match numbers used in Rybka. They have stated that the order of certain actions, where the order should be arbitrary, is consistent between the two programs.

      While this was enough to convince the judges that Rybka contained unacknowledged algorithmic influence from Fruit in the fashion required by the rules, this argument is not sufficient to show copyright infringement. Here too the comparison method should be validated by applying it to other programs which use the same algorithmic approach as Fruit and which are known to not have a shared copyright history. The Rybka investigators have failed to do this.

      Functional similarity by itself does not show copyright infringement. The clean room design model in programming is a well-understood method of using reverse engineering to create a new implementation which does not infringe on copyrights or trade secrets. One group of people reverse engineer the software and develop a design document which is reviewed by a lawyer to make sure that no copyrighted material is included. The document is passed to another group of people to implement, where the people in the second group were selected because they have no knowledge of the original implementation. An real-life example is OpenOffice, which is a clean-room implementation of Microsoft Word and is close enough in functionality that people can switch from one program to the other with little trouble.

      Rybka was not developed as a clean-room reimplementation of Fruit, and the author has long acknowledged an intensive review of the Fruit source. The point here is only to show that functional similarity is not a clear indicator of copyright infringement.

      Some may believe that reviewing the source code to Fruit means that Rybka is necessarily a derivative work. This is incorrect. A clean-room reimplementation makes it abundantly clear that there is no copyright infringement, but the lack of a clean-room style does not mean there is infringement.

      One of the most widely used computer operating systems is Linux, which was greatly influenced by the MINIX operating system. MINIX was available in source form under a proprietary license, and there was a college textbook which described how it worked and included most of the source code. The Linux author studied MINIX and ran MINIX on his computer before developing Linux. The MINIX author stated clearly that Linux is not a derived work in the copyright sense, and no review of the Linux source code has ever shown copyright infringement to any other code, including MINUX.

      Therefore, intensive review and study of the Fruit does not mean that Rybka infringes on the Fruit copyright just like an intensive review and study of MINIX does not mean that Linux infringes on the MINIX (or Unix) copyrights.

      The Rybka investigators acknowledge that no individual piece of evidence is the proverbial smoking gun. Instead, the pattern of pieces reveals the infringement. The history of evidence synthesis like this is fraught with methodological problems. Quoting from
      http://en.wikipedia.org/wiki/Meta-analysis#Disadvantages_and_weaknesses:

          The most severe weakness and abuse of meta-analysis often occurs when
          the person or persons doing the meta-analysis have an economic, social,
          or political agenda such as the passage or defeat of legislation. Those
          persons with these types of agenda have a high likelihood to abuse
          meta-analysis due to personal bias. For example, researchers favorable
          to the author's agenda are likely to have their studies "cherry picked"
          while those not favorable will be ignored or labeled as "not credible".
          In addition, the favored authors may themselves be biased or paid to
          produce results that support their overall political, social, or economic
          goals in ways such as selecting small favorable data sets and not
          incorporating larger unfavorable data sets.

      There are ways to help offset these problems. For example, all comparison methods should be reported before doing the analysis, along with the definition of what "infringing" means for that case. Methods which fail to report similarity must be recorded. All participants must state possible sources of bias, and the method for selecting the participants must also be published.

      This was not done. Of course, if there was strong evidence for copyright infringement then a careful synthesis of the evidence would not be needed, but that was not the case here. Instead, the results seem very much cherry-picked.

      It may very well be that Rybka contains copyright infringing code. It's possible, after all, that 27 lines out of 525,000 are enough to make a substantial copyright infringement claim. The problem is that the methodology of the Rybka investigators is not strong enough to be convincing.

      They claim to use the abstraction-filtration-comparison test to determine substantial similarity, but without the appropriate filtration. At each of the structural levels they fail to show that the discovery methods are not producing false positives, and they fail to demonstrate that the similarity level is greater than would be expected from a non-infringing chess program implementing the idea at the same structural level.

      The similarity between Fruit and Rybka is strongest at the highest level of the analysis, but the abstraction-filtration-comparison test acknowledges that at a high enough level there's no copyright protection. This is due to the merger doctrine.

      The document
      http://www.top-5000.nl/ZW_Rybka_Fruit.pdf is highly misleading. Without a mapping from the C structures based to disassembled code, it's impossible to judge the correctness of what the author writes. With a translation directly into idiomatic Fruit code, the visual similarities are overly distracting from the actual comparison, which is on a level that isn't show.

      (You saw in my first email that just because someone reports what the code says, it doesn't mean that that's what the code actually does.)

      Copyright law already acknowledges that at higher levels there's no copyright infringement because it's different expressions of a common idea. Hence the statement "high-level functionality is always equivalent in these cases" is meaningless unless it's established that this level is not high enough.
       
      Cheers,

                                      Andrew
       

       
      Chapter 9 - Epilogue

       

      Fast forward, now 7 months after the ICGA verdict and ban the Rybka 1 execuatable is decompiled by external software and thus without any possible human prejudice whether wished or unconsciously and available for download. It's my hope some programmers with an open mind will pick up the challenge and start comparing the 2 source codes.

       

      For sure I am not the right person to do so, I am much too biased in the between time.

       

      Thanks for listening.

      Ed Schröder
      Deventer, October 2011 - February 2012
      Netherlands


       

       

         Rybka menu | Rybka originality | Rybka fruitification | TheICGA speaks | Rule 2 | Opinion poll  | Dann Corbit

       

       

      Copyright ® 2012  Ed Schröder