FIDE Rules on ICGA - Rybka controversy

[Rebel]

"It doesn't matter what you believe, what matters is that you could not proof it"??? The evidence is overwhelming. It convinced me beyond any doubt whatsoever, not just beyond a reasonable doubt. As far as "how much is too much"? That omission is scattered throughout the law. 1.0beta was way too close to be an accident. Way too close to be original by any definition. Perhaps rybka 3 or 4 were, we will apparently never know.

You are avoiding my questions by subjective generalizations.

Once again:

How much is a programmer allowed to take from an open source?

If the ICGA can't even answer this question after 4 years then even today the rules aren't clear at all, let alone it was at the time (2005) when a TOP engine became an open source. It's one thing to overlook the effects Fruit caused, it's another thing for the ICGA to deny its responsiblity in the matter that they upon this day, 10 years later, they still can't answer this fundamental question and by the lack of clear guidance (something one might expect from a FIDE affiliated organization claiming the official world championship) that it condemned a programmer who time and time again openly stated he took many things from an open source.

The lack of an answer is the bankruptcy of the verdict.

[hyatt]

"It doesn't matter what you believe, what matters is that you could not proof it"??? The evidence is overwhelming. It convinced me beyond any doubt whatsoever, not just beyond a reasonable doubt. As far as "how much is too much"? That omission is scattered throughout the law. 1.0beta was way too close to be an accident. Way too close to be original by any definition. Perhaps rybka 3 or 4 were, we will apparently never know.

You are avoiding my questions by subjective generalizations.

Once again:

How much is a programmer allowed to take from an open source?

If the ICGA can't even answer this question after 4 years then even today the rules aren't clear at all, let alone it was at the time (2005) when a TOP engine became an open source. It's one thing to overlook the effects Fruit caused, it's another thing for the ICGA to deny its responsiblity in the matter that they upon this day, 10 years later, they still can't answer this fundamental question and by the lack of clear guidance (something one might expect from a FIDE affiliated organization claiming the official world championship) that it condemned a programmer who time and time again openly stated he took many things from an open source.

The lack of an answer is the bankruptcy of the verdict.

I've answered that question previously. It is the same answer one gets when asked to define "reckless and wanton disregard for public safety". You know it when you see it. There are dozens of laws defined the same way. "reckless driving". "criminal negligence". "negligent homocide". Etc. Etc. Etc. "too much" is "too much". 10% is probably safe. 50% is WAY too much. between those it takes judgement. That's the way it should be.

[Rebel]

I've answered that question previously. It is the same answer one gets when asked to define "reckless and wanton disregard for public safety". You know it when you see it. There are dozens of laws defined the same way. "reckless driving". "criminal negligence". "negligent homocide". Etc. Etc. Etc. "too much" is "too much".

Another subjective generalization.

1. What's too much for you is acceptable for another programmer. Can you imagine that? Or is there only the Hyatt norm?

2. No definition of "too much" in rule #2.

3. Very very confusing for a (especially new) programmer.

On which of the 3 above points do you not agree?

10% is probably safe. 50% is WAY too much. between those it takes judgement. That's the way it should be.

Numbers are something we can work on, they are more concrete and less vague than the subjective "too much", so let's reason about numbers.

Vas - I used lots of ideas from Fruit, as I have mentioned many times [ see the Vas-David correspondence ].

Count the number of ideas Vas took from Fruit.

Then define the percentage of what is too much about that number.

It's a start of a brainstorm session.

Over to you.

[hyatt]

I've answered that question previously. It is the same answer one gets when asked to define "reckless and wanton disregard for public safety". You know it when you see it. There are dozens of laws defined the same way. "reckless driving". "criminal negligence". "negligent homocide". Etc. Etc. Etc. "too much" is "too much".

Another subjective generalization.

1. What's too much for you is acceptable for another programmer. Can you imagine that? Or is there only the Hyatt norm?

2. No definition of "too much" in rule #2.

3. Very very confusing for a (especially new) programmer.

On which of the 3 above points do you not agree?

10% is probably safe. 50% is WAY too much. between those it takes judgement. That's the way it should be.

Numbers are something we can work on, they are more concrete and less vague than the subjective "too much", so let's reason about numbers.

Vas - I used lots of ideas from Fruit, as I have mentioned many times [ see the Vas-David correspondence ].

Count the number of ideas Vas took from Fruit.

Then define the percentage of what is too much about that number.

It's a start of a brainstorm session.

Over to you.

There is no percentage. In 1964 US Supreme Court Justice Porter Stewart gave a famous statement "I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["hard-core pornography"], and perhaps I could never succeed in intelligibly doing so. But I know it when I see it,"

That is good enough for the Supreme Court of the US. It is a standard used around the world. It seems "good enough" for the lowly ICGA. Vas didn't just take "ideas" from Fruit. He went much deeper. I remember when Beal published his null move paper before the 1986 WCCC event. No code given, just a general explanation about "the null-move observation." I took that, turned it into code and used it that year. Burton Wendroff (Lachex, Los Alamos Chess Program) did the same. Without ever having seen any code or implementation details. That is different from holding a program up to the light and using it as if it were a blueprint. Now you are not just copying ideas, you are copying ideas and organization and data structures. That is NOT original.

[BB+]

Meanwhile every chess player will give a rook a BONUS for being on the open file, ZERO BONUS for being behind its own pawns, and a POSITIVE BONUS for being behind the enemy pawns

I'm not sure what you mean here by "behind", is it only on the same file? At least in rook endgames, being behind your (passed) pawn is quite useful. If by "behind the enemy pawns" you mean a general invasion criterion, then it seems that an easy implementation would have been to save some "penetration" demarcator in pawneval (either rank or square based, and can also include the openness of files), and then apply this to the rook.

OK, your example. you know perfectly well that chess board pattern recognition as implemented by programmers are general purpose. Sure you can disrupt the tendency for the algorithm to put its rook on a specific file behind the enemy pawn chain by inserting a friendly pawn on a very advanced position on that same file. But what you are really trying to disrupt with this quite fanciful positioning (remember, we are discussing heavily blocked pawn frontages, with an open file penetration) is the argument that Rybka has a creative and original algorithm/pattern recognition, which is strongly superior. I''m shocked, Mark, that you stoop to this.

Some of the below (in #1) may have come from a discussion with others, I have put in (largely) my own words.

The feature tests for pawns in front and on the same file.

1) This has positive correlation to a general "penetration" criterion as a rook on the 7th/8th always gets the bonus, but it seems more likely that the "openness" of the file is its primary purpose. With penetration, the location of pawns off the tile would also be apt for consideration.

Consider, wRe1 wPf2 wPh6 bPe6 bPf7 bPh7 is scored the same as wRe5 wPf2 wPh2 bPe6 bPf7 bPh3 though the sense of penetration is quite different. This example can be made expanded, by whether the root pawn of a chain is attacked or attackable by the rook. The gazing only at pawns on the same file in front of the rook in these cases is only very weakly related to penetration. For most cases, determining whether the rook was behind many or all enemy pawns on any files, or just an enemy pawn on the same file, would better approximate penetration.

The claim that this feature is of consequent use on blocked boards is unclear too, for then the question would more often be whether the "invaded" side has any (pawn) weaknesses, and in addition whether said side can counterplay by the "open file" when the invader moves off it. Given the feature is immune to whether the file is actually "open", it doesn't form a sufficient locator for the rook. Also, the rook could more easily be in fact trapped in the situation.

2) I would be more willing to consider that the feature was some attempt at "pattern recognition" (on closed boards) if it had been done by a dopey academic. As it is, Rajlich is typically goal-oriented, and does not care about something like "implementing AI", but rather increasing ELO.

3) In its rook evaluation, Fruit does ABCDE where

• A is a calculation of mobility,
• B is a calculation of semi-open files,
• C is a calculation of open files,
• D checks whether to apply king-danger (material table flag), and if so calculates king safety with respect to semi/open files,
• E is a criterion concerning the 7th rank.

Comparatively, Rybka's rook evaluation is similarly ABCDE with the difference that the bitmasks for "semi/open files" are directional. This gives more weight to the expectation that the BC's are similar in content.

I guess one could similarly call mobility something like "future movement capacity", and note that this is a "different" notion in closed positions, and then argue that some implementation detail (like safe square mobility, or forward mobility) means that should not be classified under "mobility" at all.

(remember, we are discussing heavily blocked pawn frontages, with an open file penetration)

I am still not sure of your specific example. As noted above, the weakness of enemy pawns/squares is also of importance with blocked positions in addition to penetration, and there is no test done (in Rybka) to see if in fact the pawn frontage is heavily blocked before applying the feature, which as I say makes it as best a weak correlative.

[BB+]

// mask_open_file_w[square] is a bitmap of squares in front of the square "square" from white's perspective. If square == E2, then
// this contains 1 bits on E3, E4, E5, E6 and E7. Zeros everywhere else.

This is wrong, it also has a 1-bit on E8.

In Strelka, the initalisation is:

Code: Select all

    for (sq = i + 8; sq < 64; sq += 8)
      MaskPawnOpenFileW[i] |= (unsigned __int64)1<< sq;

In Rybka (64-bit disassembly of 1.0 version, as on the ICGA wiki), see this line

Code: Select all

0x401b48: mov    0x24a340(%r8,%r9,8),%rax        mask for open files

The relevant array is thus the 512 bytes starting from 0x64a340:

Code: Select all

0x64a340:       0x0101010101010100      0x0202020202020200
0x64a350:       0x0404040404040400      0x0808080808080800
0x64a360:       0x1010101010101000      0x2020202020202000
0x64a370:       0x4040404040404000      0x8080808080808000
0x64a380:       0x0101010101010000      0x0202020202020000
0x64a390:       0x0404040404040000      0x0808080808080000
0x64a3a0:       0x1010101010100000      0x2020202020200000
0x64a3b0:       0x4040404040400000      0x8080808080800000
0x64a3c0:       0x0101010101000000      0x0202020202000000
0x64a3d0:       0x0404040404000000      0x0808080808000000
0x64a3e0:       0x1010101010000000      0x2020202020000000
0x64a3f0:       0x4040404040000000      0x8080808080000000
0x64a400:       0x0101010100000000      0x0202020200000000
0x64a410:       0x0404040400000000      0x0808080800000000
0x64a420:       0x1010101000000000      0x2020202000000000
0x64a430:       0x4040404000000000      0x8080808000000000
0x64a440:       0x0101010000000000      0x0202020000000000
0x64a450:       0x0404040000000000      0x0808080000000000
0x64a460:       0x1010100000000000      0x2020200000000000
0x64a470:       0x4040400000000000      0x8080800000000000
0x64a480:       0x0101000000000000      0x0202000000000000
0x64a490:       0x0404000000000000      0x0808000000000000
0x64a4a0:       0x1010000000000000      0x2020000000000000
0x64a4b0:       0x4040000000000000      0x8080000000000000
0x64a4c0:       0x0100000000000000      0x0200000000000000
0x64a4d0:       0x0400000000000000      0x0800000000000000
0x64a4e0:       0x1000000000000000      0x2000000000000000
0x64a4f0:       0x4000000000000000      0x8000000000000000
0x64a500:       0x0000000000000000      0x0000000000000000
0x64a510:       0x0000000000000000      0x0000000000000000
0x64a520:       0x0000000000000000      0x0000000000000000
0x64a530:       0x0000000000000000      0x0000000000000000

Note that, in particular, 0x64a3a0 (the square e2) is 0x1010101010100000 which does indeed have the E8 square set.

You can argue that there can't be any pawns on the 1st/8th rank, but the bitmask in question checks said squares.

Note that in Fruit the board->pawn_file is updated in square_clear() and square_set() after being set in board_init_list().

[BB+]

... the thing you don't understand. Rybka gives a bonus for getting round the back of the enemy pawn chain.

The Rybka bonus is oblivious to the base of the pawn chain, or even if the opponent has any pawns at all. Black pawns on f7, g6, and h5, White pawn on a2, White rook on a3, Black pawns on a6 and b7. Rybka gives a "half-open" file bonus for the rook on a3 (whereas Fruit would not, due to the White pawn on a2). It is unclear what this has to do with "getting round the back of [either] enemy pawn chain". Furthermore, previously it was claimed the Rybka "pattern recognition" would be useful on highly blocked boards, which typically have more than one base to the pawn chain(s), weak pawns/squares, etc.

[BB+]

they (Zach and/or Mark) came accross the observation Rybka uses the quite extraordinary pawn-value of 3200 in EVAL.

The value was 3399 in early Rybkas, and then 3717 in some of the R2 versions. Kaufman changed it to 1000.

It's this kind of impressive original findings (3200) why Vasik Rajlich could dominate the computer chess world for the last 5 years, the man simply is a genius, an IM (International Master) and graduated MIT student.

Such pomposity. Kaufman is (now) a GM, also graduated from MIT, and chose 1000, rather than a tuned value.

And [hyatt] missed that he was an eyewitness of a brandnew idea in computer chess. 2 seperate scores, one in EVAL (3200) and one in SEARCH (100)

Err, this idea is so "brandnew" that similar re-scalings were already done back in the 70s. Furthermore, I don't see any particular reason to lose the extra granularity from eval when squashing it back to search, other than to keep the score fitting in (say) a 16-bit field. Possibly MTD(f) is an explanation, but there is no evidence of this with Rybka 1.0, and as Zach said, it looked like a bodging together of two separate modules of code (and indeed, the lazy eval was merged incorrectly).

[BB+]

Using the 100 system (say) we have 3 bonuses of (say) 0.04 | 0.07 | 0.12 = total 0.23
Using the 1000 system allows us to fine-tune these (same) values much better (say) 0.048 | 0.075 | 0129 = total = 252 / 100 = 0.25

I'm fairly certain the given millipawn values would round to "0.05 | 0.07 (or 0.08) | 0.13". Crafty used millipawns for awhile (I can remember them back in 1994/5 as an undergrad), and the CPW page on centipawns describes Bob Hyatt's views on this. More modernly, Kaufman used 1000 as the base in R3, though anything finer than 1/200 is rare to be used in the code, and some Houdinis also use 1/200. Stockfish uses "hexapawns" (1/256), though there is some granularity thrown away.

[BB+]

This obviously is going the wrong way. If you can't even admit a (small) mistake of your work then Mr. Schröder is done with you.

Code: Select all

             FRUIT                                 RYBKA
             if (doubled) {                        if (doubled) endgame -= 158
                opening[me] -= DoubledOpening;
                endgame[me] -= DoubledEndgame;

There is NO midgame code in Rybka. In your document it is rewarded as a 100% similarity with Fruit.

As I stated, the interpolated opening/endgame value is almost always nonzero, it is only zero at the beginning of the game until a piece is taken off the board. It does not seem useful to disregard a feature simply because one of the endpoints of the interpolation happens to be 0, which might even be caused by a compiler optimisation. Supposing a linear interpolation (as in later Rybkas, though 1.0 was non-linear), one gets the following effective (rounded) values for Rybka's doubled pawn malus, depending on the phase (=24 is the game start, as with Fruit).

Code: Select all

0 7 13 20 26 33 40 46 53 59 66 72 79 86 92 99 105 112 119 125 132 138 145 151 158

I am not sure why you want the solitary "0" term to indicate there is some significant Rybka/Fruit difference. Should a zero in the middle of some long array of weights invalidate a comparison? Why is it different when it is an endpoint? Moreover, Marsland (ICCA Journal 8/2, 1985) already mentions that while doubled pawns are usually weak, there are often compensating advantages such as a half open file or control of a key square.