Feb 12 version: Rybka 1.0 Beta / Fruit 2.1 document

[BB+]

The document concerning a comparison of Rybka 1.0 Beta and Fruit 2.1 has been reworked to some extent. There has been a re-shifting of sections, more links/pointers to code locations, and some additional disassembly examples. Two appendices have been added, the first being a disassembly of the iterative deepening code of Rybka 1.0 Beta (~100 ASM instructions at the end of root search), while the second draws together various related information (such as later versions of Rybka and statements of Rajlich). This is still to be considered as a "draft" version I guess, and any feedback (even concerning style, readability, or whatever) is appreciated.

[marcelk]

Regarding the quad() in Fruit: The approximate 10-30-60-100 values are not magical. The idea of the function is that it represents a parabola, with 100% on 7th rank and 0% on BOTH 2nd and 3rd rank. There is only one such parabola and the values for 4th to 6th rank follow directly from it.

[BB+]

Thanks. I will try to make it more clear than it is not only the 10-30-60-100 scaling, but also that it appears to be implemented in hexapawns (26-77-154-256) that makes it exceed the sense of merely re-using the idea of a quadratic fit. As noted at the end of Section 6.2.3, since Rybka pre-computes these values and puts them in an array, there is little reason to prefer 26-77-154-256 to 10-30-60-100.

How will knowing his identity make a difference to the quality and verifiability of the document?

It might compel certain persons to change their stance from "Why would you trust a document from someone anonymous?" to "Why would you trust a document from someone who preferred anonymity for so long?"

[marcelk]

Thanks. I will try to make it more clear than it is not only the 10-30-60-100 scaling, but also that it appears to be implemented in hexapawns (26-77-154-256) that makes it exceed the sense of merely re-using the idea of a quadratic fit. As noted at the end of Section 6.2.3, since Rybka pre-computes these values and puts them in an array, there is little reason to prefer 26-77-154-256 to 10-30-60-100.

After reading the rest, and on the assumption that the analysis is done faithfully, there is absolutely no doubt that R1 is derived directly from Fruit. There is no way that the root search order and variable scheme stay the same, AND the hashing scheme stays the same, AND the contents of the evaluation stay the same, AND etc etc when one is only looking at Fruit for ideas. R1 is not just inspired by Fruit: Clearly Fruit source code was taken as a starting point and then reworked from there and some parts left untouched. It is still a GPL violation to distribute it IMO without source, and a violation of most tournament rules to enter it without the consent of Fabien.

[BB+]

The search_full_root() call on line 5 of the C++ rendition of the Rybka code in Appendix A on page 19 should have the variable as depth rather than depth-2.

[Dave Mitchell]

It may violate the GPL license, but didn't Fabien give up his rights to Fruit 2.1, long ago?

[Peter C]

It may violate the GPL license, but didn't Fabien give up his rights to Fruit 2.1, long ago?

I believe they currently belong to the FSF, which is probably much worse for Vas than if Fabien still had them.

Peter

[BB+]

I found a few other minor errors, like the "enemy piece" in the Blocked Bishop need not be an enemy (nor a piece, if a pawn does not count as such). The discussion of king safety with (semi-)open files for Rooks should include adjacent files. I've also added a few more pointers to places where data can be found in the executable.

[BB+]

Another factual error: Rybka 1.0 Beta can reduce (via averaging) the shelter/storm penalty when castling rights exist.

[kingliveson]

This is a complement to the report. It is ZW's work in pdf format.