Back to R3/IPPOLIT ?

Code, algorithms, languages, construction...
Post Reply
BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Back to R3/IPPOLIT ?

Post by BB+ » Mon Feb 07, 2011 2:22 pm

M ANSARI: I think way too much is made out of this "Vas lost R3 code". There were tons of different R3 iterations when it was in beta testing. Things were added and compiled out almost daily. He probably just didn't keep track of the pre compiled source of the released version. That doesn't mean he lost all the code, just that he probably lost track of which code was the release version.
To beggar the question then (and I expect you are fully correct): why doesn't VR just state this [particularly to a forum with many programmers] in the manner that you did, rather than give the mealy-mouthed answers that many have come to expect? If the code similarities to IPPOLIT are as great as claimed, I'd fully expect any version within a week's time -- maybe even a month's -- either before or after the R3 release should suffice for most purposes [and any missing things could be filled by RE if necessary]. The main point here is then not that VR lacks the precise R3 code -- but rather that he mentions it almost as an excuse (of his own making no less), when as you say it is not all that relevant.

See also his correspondence with Schüle, who directly mentioned this in his codicil after requesting a code-snippet so as to clear up the IPPOLIT situation (either publicly, or to a trusted person like Corbit): (I assume you don't have the exact R3 source version anymore but "close" could be good enough) --- this met with the response: Re. Rybka 3 source code: Unfortunately, I don't have it. [...] I wouldn't quite call this "non-responsive", but the manner in which the question was framed seems to have taken most of the legs out of the answer, unless he really does have nothing from a rather long time span.
Milos to LK: Your values have nothing to do with actual values in Rybka 3 evaluation which were heavily automatically tuned. Anyone that can use debugger and can read your posts here (in which you brag about your evaluation values) knows that.
Having had some discussion with LK, I think he knows quite well what is in the R3 evaluation function.
Houdart: Please provide us with some real data: evaluation terms of Rybka 3, compared to evaluation terms of Ippolit.
The Appendices of my R3/IPPOLIT comparison give a sampling of this. I'd have to futz around, but if LK is willing for it to be published, a complete comparison should be possible (alternatively, LK could himself publish these, though VR might have some rights that need to be considered). I'm not sure that revealing everything in R3 would imply much more than can already be seen from the above Appendix.
LK: One way to demonstrate this [the similarity in evaluation] is to constuct an IDeA tree in the Aquarium software for all major openings, letting the program analyze each position for a minute or so. Whether you use Rybka 3, Robbo, Fire, Houdini or any other Ippo-related engine, the final values of the opening moves look remarkably similar (scaled down a bit in Houdini), and quite different from the tree resulting from using other engines like Stockfish, Shredder, Hiarcs, Naum, or Komodo.
This could be an interesting test, but again I might ask for actual data (e.g., how is "remarkably similar" quantified?), and I'd still say the actual evaluation function is a better bet than derived IDeA trees. I would be willing to do a comparison of (say) a million positions of Rybka/Houdini/Komodo/IPPOLIT/Stockfish (only the first 2 or 3 should require much work -- maybe Critter too, as it has an undocumented feature for this) if it would be of use. [I did this awhile back for IPP/R3/Fruit/Stockfish I think, but the data are at the Rybka forum, and it's probably better just to start anew].
LK: But until the Ippo family starts using a substantially different evaluation function I consider myself to be the inadvertent co-author of the evaluation functions in all of these programs ...
Although I tend to agree with this, it is not clear to me exactly what the thrust here is. Does "substantially different" mean the values, or what I consider the major R3 concept, that is, pieces attacking others (either unguarded pieces of lesser value, or "good SEE" attacks, or via x-rays, maybe guarding one's own King too)? I guess one could argue that the latter is just an idea, while the former values might be "close" via tuning [many IPPOLIT values are often "rounded to the nearest five" or close to that -- could this conceivably come from tuning with a granularity of 5?]. I think there needs to be more guidance on what it meant here by "substantially different". As stated above, the best bet might be just to take a suite of a million positions, call eval() directly on each, and do a rigourous statistical comparison.

Somewhat predictably, I think Fabien Letouzey could say something similar (though again I'd prod him to be more specific) about Rybka 1.0 through Rybka 2.3.2a. Admittedly the Fruit 2.1 values were not that well tuned, so that there is a bit more numerical difference (if I recall my data) between Rybka 1.0 and Fruit 2.1 than between IPPOLIT and Rybka 3 -- on the other hand, the "feature set" differences between Rybka 1.0 and Fruit 2.1 are almost non-existent, while they amount to maybe ~15% of the evaluation components for R3/IPPOLIT (I'd have to check the exact number, and some of the 85% matches were already in Fruit, like king safety computations via attacking a square near the opposing King).

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Back to R3/IPPOLIT ?

Post by BB+ » Sat Feb 12, 2011 2:05 pm

Regarding Rybka/Robbo, do you know whether singular extension was in 2.3.2 or just in 3.0?
If I understand the question, my hasty analysis says that, no, the "singular extensions" were not in Rybka 2.3.2a. In particular, at PV nodes there are extensions for forced evasions, recaptures, pawns to 7th, and giving check (half-ply), but nothing else. There are no extensions at CUT/ALL nodes (or low-depth nodes), other than a half-ply for giving check. This differs from R3/IPPOLIT, where both PV and CUT nodes can use the "exclude-move search" to determine if a move is singular. I am not able to locate this notion of "singular" moves in Rybka 2.3.2a (for PV nodes see for instance 0x466ac0, and for CUT/ALL nodes a place is 0x471820). Without looking too much into it, I find it plausible but rather unlikely that search in IPPOLIT was based on Rybka 2.3.2 rather than on Rybka 3. As I've pointed out elsewhere, Rybka 2.3.2a seems to have more obfuscation than Rybka 3.
There exists a vesion of Rybka 2.3.2 that did not have its symbols stripped. Would make the disassembly so much easier. It was given to various people one of whom leaked it. It was used as you know to tune Rybka and had it's own interface for that purpose.

The date of the executable is 10/5/2006.
Rybka 2.3.2 was released in June 2007 (at the start of the 2.x series, the guess-date was Nov 1 2006, or maybe Feb 12 2007). As the latter link shows, Rybka 2.2 was released around Nov 10, 2006. So it seems that the version numbering and/or date is not correct here.

User avatar
kingliveson
Posts: 1388
Joined: Thu Jun 10, 2010 1:22 am
Real Name: Franklin Titus
Location: 28°32'1"N 81°22'33"W

Re: Back to R3/IPPOLIT ?

Post by kingliveson » Sat Feb 12, 2011 6:01 pm

There was a recent interview: Mark Uniacke answers the 10 for 10 questions! and the Ippolit guys decided to have their own version: Head Comrade Yakov unquestions 10 too 10.

sample:

8. You all knew this question was coming, so let’s get it out of the way.
There is great debate over what the engines being released as a result of the Ippolit code actually are; do you believe them to be “derivatives” or “clones”?


After Ippolit there is inevitably going to be many clones and derivatives just like after Fruit there were clones and derivatives, except now it’s even more so. Sadly many people will be taken in and think these programs are genuine – it can be difficult to prove a derivative beyond all doubt especially if the “author” has obfuscated the implementation. I have been closely involved in computer chess for more than 20 years and in all that time I have never known a genuine chess engine to just emerge at the professional level at its first release (by that author), it does not mean it cannot happen but it is very unlikely, but now it’s happening all the time. Sadly I can only see the problem getting worse, and eventually (already?) most chess engines will be clones or derivatives there of. Why? Because it is incredibly easier to clone and derive than to write your own chess engine. It takes many thousands of hours of hard work and testing to produce an original top level chess program, so it should come as no surprise that there are those who prefer to avoid this work by stealing the work of others.


8. You all knew this question was coming, so let's get it out of the way. There is great debate over what the engines being released as a result of the Ippolit code actually are; do you believe them to be "derivatives" or "clones"?

http://Rybka-Is-Fruit.WikiSpaces.Com gleams lightbright for expose in Capitalist cloning vitals! IPPOLIT disgorges Fruit/Rybka internals into reassemblage plus improveds. IPPOLIT trains the already, +50 ELO beyond Rybka 3 Chess inclusioning too elephantine subcrowning (bishop).
PAWN : Knight >> Bishop >> Rook >>Queen

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Back to R3/IPPOLIT ?

Post by BB+ » Fri Feb 18, 2011 12:44 pm

It has come to my attention that the static values I listed for R3 have come into question.
http://talkchess.com/forum/viewtopic.ph ... 383#356383
http://talkchess.com/forum/viewtopic.ph ... 412#356412

The static values for Rybka 3 are loaded in the single-processor 64-bit version at 0x5859e0. Here is a dump of the 64 PST values for White pawns, each being 32 bits packed as two 16-bit entries for opening/endgame -- the other pieces follow successively in the usual manner.
(gdb) x/64wx 0x5859e0
0x5859e0:	0x00000000	0x00000000	0x00000000	0x00000000
0x5859f0:	0x00000000	0x00000000	0x00000000	0x00000000
0x585a00:	0xff1fffbe	0xff98ffbe	0xffd1ffa2	0x000aff86
0x585a10:	0x000aff86	0xffd1ffa2	0xff98ffbe	0xff1fffbe
0x585a20:	0xff24ffbe	0xff9effbe	0xffdaffa2	0x0016ff86
0x585a30:	0x0016ff86	0xffdaffa2	0xff9effbe	0xff24ffbe
0x585a40:	0xff2affc2	0xffa5ffc2	0xffe6ffa6	0x0027ff8a
0x585a50:	0x0027ff8a	0xffe6ffa6	0xffa5ffc2	0xff2affc2
0x585a60:	0xff32ffce	0xffadffce	0xfff2ffb2	0x0037ff96
0x585a70:	0x0037ff96	0xfff2ffb2	0xffadffce	0xff32ffce
0x585a80:	0xff3cffdc	0xffb9ffdc	0xfffeffc0	0x0043ffa4
0x585a90:	0x0043ffa4	0xfffeffc0	0xffb9ffdc	0xff3cffdc
0x585aa0:	0xff50fff0	0xffcdfff0	0x0012ffd4	0x0057ffb8
0x585ab0:	0x0057ffb8	0x0012ffd4	0xffcdfff0	0xff50fff0
0x585ac0:	0x00000000	0x00000000	0x00000000	0x00000000
0x585ad0:	0x00000000	0x00000000	0x00000000	0x00000000
See http://rybkaforum.net/cgi-bin/rybkaforu ... 4#pid16484 for more about the "q_checks_margin_min_1_opening" issue.

Jeremy Bernstein
Site Admin
Posts: 1226
Joined: Wed Jun 09, 2010 7:49 am
Real Name: Jeremy Bernstein
Location: Berlin, Germany
Contact:

Re: Back to R3/IPPOLIT ?

Post by Jeremy Bernstein » Fri Feb 18, 2011 12:58 pm

BB+ wrote:It has come to my attention that the static values I listed for R3 have come into question.
http://talkchess.com/forum/viewtopic.ph ... 383#356383
http://talkchess.com/forum/viewtopic.ph ... 412#356412

The static values for Rybka 3 are loaded in the single-processor 64-bit version at 0x5859e0. Here is a dump of the 64 PST values for White pawns, each being 32 bits packed as two 16-bit entries for opening/endgame -- the other pieces follow successively in the usual manner.
(gdb) x/64wx 0x5859e0
0x5859e0:	0x00000000	0x00000000	0x00000000	0x00000000
0x5859f0:	0x00000000	0x00000000	0x00000000	0x00000000
0x585a00:	0xff1fffbe	0xff98ffbe	0xffd1ffa2	0x000aff86
0x585a10:	0x000aff86	0xffd1ffa2	0xff98ffbe	0xff1fffbe
0x585a20:	0xff24ffbe	0xff9effbe	0xffdaffa2	0x0016ff86
0x585a30:	0x0016ff86	0xffdaffa2	0xff9effbe	0xff24ffbe
0x585a40:	0xff2affc2	0xffa5ffc2	0xffe6ffa6	0x0027ff8a
0x585a50:	0x0027ff8a	0xffe6ffa6	0xffa5ffc2	0xff2affc2
0x585a60:	0xff32ffce	0xffadffce	0xfff2ffb2	0x0037ff96
0x585a70:	0x0037ff96	0xfff2ffb2	0xffadffce	0xff32ffce
0x585a80:	0xff3cffdc	0xffb9ffdc	0xfffeffc0	0x0043ffa4
0x585a90:	0x0043ffa4	0xfffeffc0	0xffb9ffdc	0xff3cffdc
0x585aa0:	0xff50fff0	0xffcdfff0	0x0012ffd4	0x0057ffb8
0x585ab0:	0x0057ffb8	0x0012ffd4	0xffcdfff0	0xff50fff0
0x585ac0:	0x00000000	0x00000000	0x00000000	0x00000000
0x585ad0:	0x00000000	0x00000000	0x00000000	0x00000000
See http://rybkaforum.net/cgi-bin/rybkaforu ... 4#pid16484 for more about the "q_checks_margin_min_1_opening" issue.
These 16-bit values are understood how? Let's take a7 (I suppose) for instance: 0xFF1F / 0xFFBE = 65311 / 65470. This is certainly not the raw worth of a pawn in Rybka, so what further conversion is necessary?

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Back to R3/IPPOLIT ?

Post by BB+ » Fri Feb 18, 2011 1:02 pm

Each 16-bit entry is signed (I guess one could say: "Just like IPPOLIT"...). So 0xFFBE is -0x42 (if I'm still awake), which is -66, with the scaling in millipawns. You also need to be careful with carries in this representation. Finally, you didn't exactly take "a7", as the numbering starts at a1, b1, c1, ..., a2, b2, c2, ..., and at the bottom of the ASM dump is e8, f8, g8, h8. See the table in Appendix A.1.4 of the R3/IPPOLIT report, which gives White-oriented grids.

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: Back to R3/IPPOLIT ?

Post by BB+ » Sat Feb 19, 2011 6:23 am

In any event, I've been more careful about citing specific disassembly locations in the Fruit/Rybka document than in R3/IPPOLIT (though part of their elision in the latter was because R3 is not freely available). I don't have 1300 footnotes over 475 pages, so there's no excuse. :lol:

Post Reply