The Evidence against Rybka

[hyatt]

do not disagree at all. However, THAT is exactly what we have been "getting" as you know...

"it just has to be wrong..."

[lmader]

People really do need to download the report.

It is a bit annoying that there are still some who seem quite unaware of even the basis for the ICGA decision to disqualify Rajlich's entries [whether or not they agree with it]. This could be due to the information not being immaculately organised, though mis-information/mis-direction must play some part too. Perhaps if I find the time, I will write something briefly on this. The FSF guy was also interested in such a summary, but he then seemed to say that the current information was enough, so I never bothered.

I don't think there is any level of immaculate organization that would make a difference. I think most people who don't bother to read it suffer from one or more of the following:

1) Just too lazy. If this is the case they have no business disputing it.
2) Afraid that they can't understand the technical details. If this is the case they have no business disputing it.
3) Are belief oriented rather than evidence oriented. This is really the major problem with most of the deniers. They are caught in their belief of a thing and no amount or reason/evidence can affect that type of thinking. It's like being religious. It's the epistemology of "the truth is what makes me feel good".

IMHO, the documents are already very well organized and not difficult to understand.

Cheers,
Lar

[Uly]

I would say that by themselves these snippets are not as significant as the "evaluation overlap" finding, though they do serve to bolster the overall picture that the "origins" of Rybka 1.0 Beta were indeed in Fruit 2.1.

I don't think that has been challenged, people on the other side have accepted that Rybka is "based" on Fruit.

What is being discussed is if the report manages to show proof of "code copying" or just of "dependence" [Dagh Nielsen]

I.e. if the report tells us more than what we already knew because Vas told us "I went forward and backwards through the Fruit sources and took many things".

[kingliveson]

Lord have mercy! Seriously, it must be that some have a weird fetish with this whole controversy and get off of it. I mean the case has been going on for years, and adjudicated . Is it not time to let it go? This thing has become cyclically stale and boring.

How 'bout we talk more interesting topics like why Houdini is destroying the competition -- how it sees a mate in less than a milli-second, yet the next best thing cant in 5 minutes or at all, or how it handles fail-lows /fail-highs and prunes like no other, or whatever else makes it a beast.


Time to move on,

Franklin

[Uly]

How 'bout we talk more interesting topics like why Houdini is destroying the competition

If Houdini is the topic of discussion, I'd find more interesting to discuss why is it lagging behind Rybka and other engines like Critter for analysis of Correspondence games despite the new learning feature that was introduced and that its elo is much higher for unassisted games? Is it the evaluation or what?

[Rebel]

What is this code for? - please don't tell me it's from the UCI parser....

I removed the comments, as it appears that's been called "fantasy code". Perhaps I should just give up trying.

No, please don't

But as you are used to criticize RF postings here I was wondering why you (yet?) did not address the what's called Fruitication issue.

I am also curious if you can explain why dozens of values simply can't be found in the R1 executable, a few examples.

From Zach's document:

Rook mobility (Rybka)
static const int RookSemiKingFileOpening = 121;
static const int RookKingFileOpening = 974;

974 not in R1 executable

-------------------------------------------------

Shelter values (Rybka)
const int shelter_value[5] = { 1121, 0, 214, 749, 915 }

1121 not in R1 executable
749 not in R1 executable
915 not in R1 executable

I have a lot more of those but I think 2 examples suffice.

I assume there is rational explanation for this as since the volume excludes a simple typo.

[wgarvin]

From Zach's document:

Rook mobility (Rybka)
static const int RookSemiKingFileOpening = 121;
static const int RookKingFileOpening = 974;

974 not in R1 executable

Actually it is, the compiler just subtracted 121 from it during optimization (853 + 121 = 974).

From R1x64eval.txt on the ICGA wiki:

Code: Select all

0x401b86: add    $0x79,%esi                        if so, add 121 in opening
0x401b89: test   %rdx,%rax                          and if file is same as bK
0x401b8c: je     0x401baf
0x401b8e: add    $0x355,%esi                         add 853 more in opening

Shelter values (Rybka)
const int shelter_value[5] = { 1121, 0, 214, 749, 915 }

1121 not in R1 executable
749 not in R1 executable
915 not in R1 executable

Remember, you're looking for little-endian values (first byte is the lowest 8 bits).

1121 is "61 04"
 214 is "D6 00"
749 is "ED 02"
 915 is "93 03"

All of these values are found (several times) in a table from about file offsets 0x22380 to 0x24380 in the Rybka 1.0 Beta 64-bit exe.

I did not check with a debugger and I don't have a disassembly tool handy, so I'm not 100% sure, but it sure looks like a table with the shelter values mixed in with other values.

Zach, feel free to correct me if I'm wrong.

I have a lot more of those but I think 2 examples suffice.

I assume there is rational explanation for this as since the volume excludes a simple typo.

Yes, there are rational explanations.  It took me about 5 minutes to find the answers to these two examples, bring on the rest of em and hopefully they will be easy to explain also.

[wgarvin]

Formatting that post on my cell phone took longer than finding the actual values. arrrg. From now on I'll just wait til I get home and can post with a real browser!

[wgarvin]

If you load Rybka 1.0 Beta 64-bit under a debugger (I used Visual Studio) you will find the table at 0x423B80--0x425B80 or so. I don't know how its indexed, but it contains 128 copies of "61 04", 512 copies of "D6 00", 256 copies of "ED 02" and 128 copies of "93 03".

[Rebel]

From Zach's document:

Rook mobility (Rybka)
static const int RookSemiKingFileOpening = 121;
static const int RookKingFileOpening = 974;

974 not in R1 executable

Actually it is, the compiler just subtracted 121 from it during optimization (853 + 121 = 974).

From R1x64eval.txt on the ICGA wiki:

Code: Select all

0x401b86: add    $0x79,%esi                        if so, add 121 in opening
0x401b89: test   %rdx,%rax                          and if file is same as bK
0x401b8c: je     0x401baf
0x401b8e: add    $0x355,%esi                         add 853 more in opening

HI Wylie,

So what you are saying is that you got 2 only values (853 and 121) and that that justifies the creation of a non existence constant in Zach's document -> static const int RookKingFileOpening = 974; because the Fruit source dictates that ?

Remember, you're looking for little-endian values (first byte is the lowest 8 bits).

I know but IDA takes care of that.

Yes, there are rational explanations.  It took me about 5 minutes to find the answers to these two examples, bring on the rest of em and hopefully they will be easy to explain also.

Okay, let's do them one by one.