Feb 12 version: Rybka 1.0 Beta / Fruit 2.1 document

[BB+]

I think Zach is going to re-work his "horribly bogus" contribution, probably with verifiable citations to ASM code. He has an IDAPro project (or whatever they call them), but he either couldn't find or had lost some details external to it.

[BB+]

Another minor problem is that (see 6.2.1) the "AttackerDistance" and "DefenderDistance" in Fruit and not constants in Rybka, but are rather rank-based. A new re-write of this document should be coming out soon -- there's also a question of what parts of this are most relevant for Fabien's FSF complaint.

[kingliveson]

Another minor problem is that (see 6.2.1) the "AttackerDistance" and "DefenderDistance" in Fruit and not constants in Rybka, but are rather rank-based. A new re-write of this document should be coming out soon -- there's also a question of what parts of this are most relevant for Fabien's FSF complaint.

It really shouldn't be about what's relevant, but rather code copy.

[gaard]

Another minor problem is that (see 6.2.1) the "AttackerDistance" and "DefenderDistance" in Fruit and not constants in Rybka, but are rather rank-based. A new re-write of this document should be coming out soon -- there's also a question of what parts of this are most relevant for Fabien's FSF complaint.

I haven't been keeping up with a lot of this. Are you sure that Fabien is writing a complaint to the FSF?

[BB+]

I haven't been keeping up with a lot of this. Are you sure that Fabien is writing a complaint to the FSF?

Yes.

[BB+]

The latest version of the PDF should be ready in a few hours. I just need to dump some stuff here so as to get some URLs to include. As to whether it will be worth reading (yet again), I can quote Mig on the Rybka/Junior fall-through back in 2007:

I know you and I know you don't have anything better to do this weekend than read an eight-page article that gives the blow-by-blow behind the scenes action of a computer match that isn't going to happen. Coincidentally, just the other day IM David Levy sent me just such a document! [...]

[BB+]

Probably no reason to start a new thread, so I'll just stick it here. Not that many changes beyond the cosmetic, though I guess I give a few more details regarding code locations and the such.

[BB+]

I might make a comment about the "Conclusion" -- perhaps I used this word in a colloquial sense meaning more of "Recapitulation" (or perhaps as in concluding the paper, rather than saying anything "conclusive" about the issue). In particular, the Conclusion does nothing more than briefly re-state the evidence. Though I occasionally interspersed my own opinions (and/or clarifications of context) at various places in the document, on the whole it was intended to be evidentiary rather than argumentative, and I leave it to others to form their own conclusions about the value of such evidence. For instance, perhaps some programmers would read it and say: "Yes, this is all true, but everyone else in the field does the same, and it's generally accepted."

[BB+]

Some clarifications:
Firstly, in the hashing section (6.1) I note that the first 8 bytes are used/ordered the same, and perhaps the reader might conclude the second 8 had nothing in common. This is not true, as both Fruit 2.1 and Rybka 1.0 Beta have min/max scores (2 bytes each) and min/max depths (1 byte each). It seems that this min/max split is quite rare (though not unseen) for a PVS engine, but I elided this item on the grounds that perhaps it was merely an "idea" from Fruit.

Secondly, in the evaluation section, I might emphasise that not only is the notion of mobility the same in Fruit 2.1 and Rybka 1.0 Beta (see footnote 4), but also the overall effect on the evaluation in both is linear in the number of squares attacked. For comparison, here is the numerology from Pepito:

Code: Select all

static const int MOV_ALFIL[14] = {-10, -5, 2, 3, 5, 6, 7, 8, 10, 10, 10, 10, 10, 10};
//static const int MOV_ALFIL[14] = {-15, -5, 2, 3, 5, 10, 15, 15, 15, 15, 15, 15, 15, 15};
static const int MOV_TORRE[15] = {-5, - 3, 2, 3, 4, 5, 6, 7, 8, 8, 8, 8, 8, 8, 8};
//static const int MOV_CABALLO[9] = {-15, -4, 1, 2, 3, 4, 5, 7, 7};

Similarly for Phalanx XXII:

Code: Select all

int B_mobi[20] =
 { -36, -28, -20, -14, -6, -2, 1, 2, 3, 4, 5, 6, 7, 8, 8, 8, 8, 8, 8, 8 };
int R_mobi[16] =
 { -9, -5, -2, 0, 2, 4, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6 };

Also, for comparison to the 26-77-154-256/10-30-60-100 scaling for Fruit 2.1 and Rybka 1.0 Beta in passed/candidate pawns, here is Pepito:

Code: Select all

static const int PEON_PASADO[8] = {0, 5, 15, 30, 55, 75, 100, 0};
static const int PEON_PASADO_BLOQ[8] = {0, 5, 15, 20, 40, 60, 85, 0};
static const int REY_APOYA_PASADO[8] = {0, 0, 0, 0, 5, 20, 60, 100};

Another minor similarity is that Rybka 1.0 Beta and Fruit 2.1 both have constant penalties for pawn defects (isolated/backward/doubled), while some (certainly not all, maybe not even most) engines have rank- or file-based numerology for some of these. For instance, Phalanx XXII has, well, I'm not sure whether it's file or rank [the comments conflict], but it's something for isolated pawns:

Code: Select all

/* isolated pawn penalty by rank */
static const int isofile[10] =
{ 0, -4, -6, -8, -10, -10, -8, -6, -4, 0 };
/***  A   B   C    D    E   F   G   H  ***/

PS. 2451 downloads of the PDF! [2454 by the time I finished editing!]

[Jeremy Bernstein]

PS. 2451 downloads of the PDF! [2454 by the time I finished editing!]

Maybe some of those people will read it, too!

Thanks for the clarifications and comparisons. Much appreciated.

jb