Q. What are the principal similarities between Rybka 1.0 Beta and Fruit 2.1?
A. I will simply stress the evaluation functions, as the search functions have more differences. Both use exactly the same features (for every piece). Mobility and nothing else for minors, additionally 7th rank for queens, all this and (half-)open files for rooks, blocked bishops/rooks --- it's all the same, as is the criterion for king attacks, the method for passed pawns (including the 10:30:60:100 scaling on every sub-feature), and much of the pawn evaluation.
More examples are the identical "flags" in the material tables, giving the same criterion for when to use king safety, and similarly for when to halve the eval score in an opposite bishop ending. There is also the exact same internal scaling (in all 8 or 9 cases) in the piece-square tables, with the only structural difference in the whole PST process being a minor difference in bonuses for central pawns.
I do not think there is any possible way one could argue that the evaluation function(s) of Rybka 1.0 Beta are remotely "independent" of those of Fruit 2.1 according to the traditional standards of computer chess. A comparison of Fruit 2.1 with Crafty or Glaurung (or Pepito, or Gerbil, or Faile, or Phalanx, or likely any other pre-Fruit engine) will indicate that this is not within the realm of coincidence.
Q. What are the principal differences between Rybka 1.0 Beta and Fruit 2.1?
A. Rybka 1.0 Beta uses bitboards, has an extensive material imbalance table, and does not have the history pruning which Fruit 2.1 made prominent, but has a more vanilla approach that only considers the location in the move list. The values/weightings of the evaluation features are also of course different.
The search function of Rybka 1.0 Beta follows that of Fruit 2.1 in a vague sense, but seems not to be as mature; for instance, Rybka 1.0 Beta simply announces mate and does not try to minimise the distance to it (which can lead to overly lengthy mating chases). The principal "new idea" in search seems to me to be the passage beyond the strict cutoff values used in AEL pruning with respect to futility.
These add up to about 75-100 elo improvement on a 32-bit machine, comparable to the amount that Fruit itself gained over the second half of 2005.
Rybka 1.0 Beta also lacks underpromotions, which is quite odd for such a strong engine. One can note that the "predecessor" Rybka 1.5.32 from March/April 2004 included at least rook underpromotions, playing one against Taktix in Round 3.2 of the Top 200 of Le Système du Suisse (season 3), and also one against Chess System Tal II in Round 8.3 of ChessWar V E.
Q. Is there any code from Fruit 2.1 in Rybka 1.0 Beta?
A. I would say yes, and this is particularly clear in various parts of the UCI parsing. One example (in the position UCI command) is given here and in the following discussion. However, there is various mis-information around concerning the extent of any copying of UCI parsing, as for instance [url=http://ct_chess.pagesperso-orange.fr/Fruit-Rybka/start_go.html]this[/url] purports to give a "side-by-side" comparison of the "go" parser, but the Rybka 1.0 Beta order of parsing is re-ordered to fit the conclusion (it is not alphabetical [binc, btime, depth...] as with Fruit 2.1). Rick Fadden gives the Rybka 1.0 Beta disassembly and a more proper C translation here.
What makes this all the more strange is that the predecessor Rybka 1.5.32 was already a UCI engine, and thus it would be more logical to re-use that code rather than "borrow" from Fruit 2.1. The occurrence of "0.0" (as per Fruit 2.1) in the otherwise integer-based time management code of Rybka 1.0 Beta is another piece of evidence that is hard to dismiss, even if one demands a "copy/paste" standard rather than one akin to "plagiarism" for code copying.
Q. Is there chess-specific Fruit 2.1 code in Rybka 1.0 Beta?
A. I do not know of any direct evidence of this, such as would occur when (say) local variables are allocated in an identical manner by a compiler. The use of bitboards would preclude any mechanical copying of the evaluation function in any event. If you consider "data structures" to be code, then the identical use of the first 64 bits of the hash entries [lock(32), move(16), depth(8), date(8)] would be one point of non-independence, with again other open source engines notably differing so as to deflect any cry of "coincidence" (e.g. Faile uses [hash, depth, score, move] with differing bit widths; even Fruit 1.0 differs, having a 64-bit lock).
Here is a high-level comparison of the root search (see ZW's analysis)
Code: Select all
[b]Fruit 2.1[/b] [b]Rybka 1.0 Beta[/b]
generate legal moves generate legal moves
limit depth to 4 if #moves is 1 limit depth to 4 if #moves is 1
setup setjmp setup setjmp
list/board copy
reset/start timer start timer
increment date and date/depth table increment date and date/depth table
reset killers then history (sort_init) reset killers then history
copy some Code()/UCI params
score/sort root list score/sort root listQ. What is your conclusion about Rybka 1.0 Beta and Fruit 2.1?
A. Rybka 1.0 Beta contains too much that is unique to Fruit 2.1 to consider it to be truly "independent" by the traditional standard of computer chess. This seems to have remained true until the evaluation was rewritten in Rybka 3 (the eval of Rybka 2.3.2a has only minor differences from that of Rybka 1.0 Beta, and various of the remnants of the internal PST scaling also remain). The Fruit-facets that still remain are fairly pedestrian, such as the 1:2:4 phase scaling with linear interpolation in the evaluation.
Rybka 1.0 Beta also likely violated the Gnu GPL by copying part of the UCI parser code of Fruit, though by now this seems moot, and it would be the prerogative of Fabien Letouzey to pursue this. The question of "intellectual property" is dismissed by Letouzey in an email to Dann Corbit (see here) though he does note that "Tournament organisers might think differently."
