Material table "drawishness" in R3/IPPOLIT

[BB+]

This seemed like a good thing to explicate.

Both R3 and IPPOLIT have a "token" in the material value/adjustment table that controls the "drawishness". The function for this in IvanHoe is "InitTokens" in the file material_value.c ("initSHKALA" in IPPOLIT.c, if you care).

Here are the IPPOLIT values (in hexadecimal):

Base value     0x80
R and oppB     0x70 + MAX
OppB ending    0x30 + 4 * MAX
Knight ending  0x80 + MAX
SameB ending   0x78 + 2 * MAX
Rook ending    0x60 + 2 * MAX
Queen ending   0x70 + MAX
Pawn ending    0xc0 - 8 * MAX

Here MAX means the maximum of the number of white pawns and black pawns. For instance, an opposite bishop ending where one side has 6 pawns and the other has 5 would have the evaluation multiplied by 0x48/0x80 (or 9/16).

The Rybka 3 method is a bit more complicated (and contains an error, I think). Here is a "spec" for it (I leave CW to implement it). In all cases, if the PAWN_CRITERION (below) is true, the result is 0x80. This is the only adjustment for the number of pawns.

Base value        0x80
OppB and knight   0x6c
OppB and rook     0x66
OppB and queen    0x6c
OppB unbalanced   0x73 [e.g. RB vs BN, bishops opp colours]
OppB (and pawns)  0x39
Knight ending     0x88
Same B ending     0x8c
Rook ending       0x80
Queen ending      0x73
Pawn ending       0xc0

The Rybka PAWN_CRITERION seems a bit quirky/buggy to me because it is not symmetric. If each side has at least 5 pawns and White has (strictly) more pawns than Black, then the PAWN_CRITERION is true. If not, it is false.

The function to compute this appears in 64-bit Rybka 3 at 0x45fd80, though this function does much more that just compute "tokens" (and in general is a horrendous case-based mess), with the relevant part being a couple thousand lines below (search for "0x73," for instance). The material table itself gets loaded at 0x712410 (see the 0x312410 offset in the evaluation functions, for instance), with the relevant bytes for the tokens being the 2nd in groups of 4, but you'd still have to know how the table is indexed to be able to reconnoiter its contents (well, it's no real mystery -- IPPOLIT uses the same indexing!).

I like this example because it shows a typical case of how IPPOLIT uses "ideas" but the realisation has a number of differences. It should be noted that there is another test for "drawishness" (for instance, BN vs B with no pawns is a draw, RB vs R is hard to win) that is folded into the material table, and there is also another "drawishness" considered in the pawn evaluation code [see Appendix A.3.2 of the R3/IPPOLIT report].

[kingliveson]

You keep posting these kinds of internal details, and people could confuse you with Igor Igorovich Igoronov or Azaad.

By the way, do you care to share which tool you use, if not publicly, privately? -- or not at all would be fine as well.

[BB+]

By the way, do you care to share which tool you use, if not publicly, privately?

For the above, at first I just had the R3 material imbalance table, which as I say, can be determined via the access near the top of the eval function. Using gdb (under Linux with microwine) I dumped this to disk. Trying to make head-or-tail out of the 419904 entries is a bit difficult, and I say, the ASM code that makes this table is a massive headache to unravel. [One can see, though, that it is "not the same" as the IPPOLIT table rather easily]. Instead, I made a toy program [one could follow the IPPOLIT "template" to know how it vaguely might look, though here that is of somewhat limited value] to try to replicate the table entries, and after some trial-and-error (particularly with the PAWN_CRITERION), this was successful.

The asymmetry of the PAWN_CRITERION might be VR trying to detect "cloners" (rather than a "bug"), but if so, I'd posit the table as a whole would already suffice for that.

[kingliveson]

By the way, do you care to share which tool you use, if not publicly, privately?

For the above, at first I just had the R3 material imbalance table, which as I say, can be determined via the access near the top of the eval function. Using gdb (under Linux with microwine) I dumped this to disk. Trying to make head-or-tail out of the 419904 entries is a bit difficult, and I say, the ASM code that makes this table is a massive headache to unravel. [One can see, though, that it is "not the same" as the IPPOLIT table rather easily]. Instead, I made a toy program [one could follow the IPPOLIT "template" to know how it vaguely might look, though here that is of somewhat limited value] to try to replicate the table entries, and after some trial-and-error (particularly with the PAWN_CRITERION), this was successful.

The asymmetry of the PAWN_CRITERION might be VR trying to detect "cloners" (rather than a "bug"), but if so, I'd posit the table as a whole would already suffice for that.

I think that I now remember Zach mentioning somewhere you using gdb -- sounds painful. Something comparable in Windows would be OllyDbg.

[jury_osipov]

BB+.
Have you managed to get out a compiled working project from disassemby code?
I do not remember who I asked about this - you or Zach.

[BB+]

BB+.
Have you managed to get out a compiled working project from disassemby code?

It depends on what you mean. If you mean a complete Rybka 3 emulator, then the answer is no. I have written C code to emulate specific parts such as the pawn evaluation function, but there again some of it can just be a mechanical translation (with variables names like "eax" for instance).