FIDE Rules on ICGA - Rybka controversy

[hyatt]

You insist on calling this situation half open/open file, but it isn't is it? The chess definition half open or open simply does not apply to a own pawn ALSO on file. Why do you insist on the false definition? Because you are unconsciously biased to force Rybka code into parallels with Fruit structures, even when that steucture does NOT exist in Rybka.

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.

Why don't you show the exact place where Rybka gives a bonus when its rook is BEHIND enemy pawns.

The only code I can find says this:

(1) if there is no friendly pawn in front of the rook, give a half-open file bonus.

(2) If there is no enemy pawn in front of the rook, give an open file bonus and remove the half-open file bonus.

If you want to say that "gives a bonus for being behind a pawn" that looks like pretty fanciful dreaming. Anyone can, with a little bit of reasoning, determine EXACTLY what his intent was. Because the concept of half-open/open is pretty obvious, and his intent was to slightly modify half-open to include the case where the friendly pawn is behind the rook. I ran this exact change a few years ago and it was a ZERO elo change, although the Elo did drop a couple of points but that was within the error bar and I did not feel like testing for +/- 1 accuracy. Guarantee you that his intent was NOT a rook behind enemy pawns there, that is serendipity and maybe not such good serendipity either.

hahahahaha!! can you read ASM? find it yourself and work it out. Ridiculous question.There's a Rybka bonus (in the discussed code) for rook behind blocked enemy pawn chain, a common pattern. Fruit "parallel" code (your parallel) simply doesn't have this bonus. Ask Mark to explain it to you, at least he has seen it already.

I'm reading your second paragraph, excuse me whiel I pick myslef up off the floor. First mind-reading doesn't cut it. Second, you are applying Morton's fork now that you maybe finally understand the code. For you, it was the same (it wasn't of course) therefore he copied. Now, you realise it is very different, but, of course, now he copied and modified it. hahahahahahaha!!! Vas ls lost in all variations according to the brillient Hyatt logic. Same = copied. Different = copied and modified. So stupid, you expect anyone to believe your nonsense?

There is no code that even RECOGNIZES a "blocked pawn chain." Sorry. More made-up nonsense. And it is EASY to understand his intent. The code at hand is NOT intended to recognize a rook BEHIND enemy pawns. If it were, WHY would it care whether it had an own-pawn on the file at all or not? It does care, because it was designed to work EXACTLY as explained. Rook on half-open or open file. Vas changed one minor point, namely to call a file half-open if there are no friendly pawns in front of it. There are LOTS of things wrong with this idea. You have a pawn at e7, enemy pawn at e6, no other pawns on board. Is your rook useful on the e-file or not? Vas doesn't think so. It is simply obvious what his intent was, and it had nothing to do with your fertile imagination...

As far as this code, I have ALWAYS understood it. It is not exactly rocket science... Fruit has EXACTLY the same pair of bonuses, only it requires NO friendly pawns on the file for it to be considered half-open, while Rybka requires no friendly pawns in front of the rook. In 99% of the cases they are exactly the same, since for most of the game the rooks are generally found on the first or second rank.

And you talk about mind-reading in one sentence and come up with that "rook behind a blocked enemy pawn chain with a straight face?

Please show me THAT code.

My analysis is absolutely correct. I can't help it if you are so utterly confused. This is not an insult, this is the truth.

If you fail to analyse, or even see, at an incredibly simple level what Rybka is actually doing with this code, then any and all conclusions you come to will be nonsense.

Your points 1 and 2 above do NOT describe the action of the Rybka code. I am not going to discuss more complex functionality arising, with you, when you are wrong at such a simple level. What has happened to you, man? You used to at least read code accurately, in the past.

So it seems "imagination" is the correct term. There is no code that recognizes your "blocked pawn chain" anywhere in the code. Which I already knew before looking. My points 1 and 2 describe EXACTLY what the code does. EXACTLY. C code is, by definition, non-ambiguous. Be pretty useless otherwise.

[hyatt]

Rybka is NOT "different here".

What

Zach and Mark admit that in their documents.

Why don't you stop cutting things OUT OF CONTEXT?

The full statement:

Rybka is NOT "different here". In 1992 Stanback and I were talking at an ACM event and we discussed the idea of evaluating a "rook lift" since we both did it

We were talking about the idea of rook in front of pawn. What Rybka did is NO DIFFERENT that what we were doing in the early 90's to evaluate the usefulness of a "rook lift". Not a MENTION of the word "fruit" in that statement. Not a mention of anything related to Zach or Mark. Again, distortion.

[hyatt]

If you want to say that "gives a bonus for being behind a pawn" that looks like pretty fanciful dreaming. Anyone can, with a little bit of reasoning, determine EXACTLY what his intent was.

And there we go again, assumptions.

FACT - Rybka <> Fruit

Get your facts first, then you can distort them as you please.
-- Mark Twain

Ed, incredibly, he hasn't even analysed correctly what the bitwise AND operations on the file are doing. So, his basic facts are false! It's impossible to discuss with him, we are on the complexities arising, and he can't even get the raw simple stuff right. Hopeless. What's happened? I used to be able to count on at least some sort of technical sense from Bob, but now?

They (Zach, Bob, Mark) completely missed what this pawn-rook code does. They tried to shoehorn the Rybka code into the MODEL they had of Fruit code. They didn't recognise Rybka was working to a different conceptual model. And they tried to call the differences unimportant, then use Morton's Fork (or Catch 22): if same-copied. If different-copied and modified. Guilty in all variations. hahaha!!

It looks as if our three Mouseketeers are just insufficiently skilled at the CHESS to be able to follow the CHESS CODE of an International Master. Hyatt thinks it's all about ASM and programming expertise, but he's wrong, you need CHESS expertise as well. This example beautifully demonstrates.

OK, I'll bite since you can't read code.

Here is the code. Comments added by me:

// 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

file_bb = mask_open_file_w[square];

// we take the bit board that has a 1 on every square where a white pawn stands, and we AND that with the above mask. If that is
// zero, there are no white pawns on the file in front of this pawn. So we add in a bonus for a "pseudo-half-open file" for this rook

if ((Board.pieces[WP] & file_bb) == 0) {
opening += RookSemiOpenFileOpening; endgame += RookSemiOpenFileEndgame;

// we take the bit board that has a 1 on every square where a black pawn stands, and we AND that with the same file mask from above,
// if that result is zero, then no black pawns stand in front of this rook either. So we remove the "pseudo-half-open-file" bonus and add
// in the "pseudo-open-file" bonus instead.

if ((Board.pieces[BP] & file_bb) == 0) { opening += RookOpenFileOpening - RookSemiOpenFileOpening;
endgame += RookOpenFileEndgame - RookSemiOpenFileEndgame;
}


Now feel free to show me where Ed, incredibly, he hasn't even analysed correctly what the bitwise AND operations on the file are doing. comes from. It would appear to be YOU that can't read and understand code. BTW I will tell you the same thing I told Ed back in 2011. If you want to know what is in that mask_file_open_w[square] value, run it under the debugger and actually LOOK.

Feel free to try again, you certainly fell flat on your face here. Nothing about blocked pawn chains and such. If the intent was to catch rook behind enemy pawns, you would CERTAINLY want to do it right, which this does not. Mark pointed out that for white, with a rook on e7, white pawn on e6, black pawn on e5 this does NOT work in a rational way. Because it wasn't intended to catch that case anyway. What it was _intended_ to do is obvious. That it has a pretty unimportant "bug" is meaningless. You CAN take any program of your choice and add this to verify it provides ZERO Elo or even hurts Elo by a couple of points. It is more bug, less intent.

Rook_on_7th is the usual way to attract the rook behind enemy pawns. Rybka does that just like everyone else.

[hyatt]

If you guys would stop removing context, even YOU might understand the statements...

[Chris Whittington]

You insist on calling this situation half open/open file, but it isn't is it? The chess definition half open or open simply does not apply to a own pawn ALSO on file. Why do you insist on the false definition? Because you are unconsciously biased to force Rybka code into parallels with Fruit structures, even when that steucture does NOT exist in Rybka.

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.

Why don't you show the exact place where Rybka gives a bonus when its rook is BEHIND enemy pawns.

The only code I can find says this:

(1) if there is no friendly pawn in front of the rook, give a half-open file bonus.

(2) If there is no enemy pawn in front of the rook, give an open file bonus and remove the half-open file bonus.

If you want to say that "gives a bonus for being behind a pawn" that looks like pretty fanciful dreaming. Anyone can, with a little bit of reasoning, determine EXACTLY what his intent was. Because the concept of half-open/open is pretty obvious, and his intent was to slightly modify half-open to include the case where the friendly pawn is behind the rook. I ran this exact change a few years ago and it was a ZERO elo change, although the Elo did drop a couple of points but that was within the error bar and I did not feel like testing for +/- 1 accuracy. Guarantee you that his intent was NOT a rook behind enemy pawns there, that is serendipity and maybe not such good serendipity either.

hahahahaha!! can you read ASM? find it yourself and work it out. Ridiculous question.There's a Rybka bonus (in the discussed code) for rook behind blocked enemy pawn chain, a common pattern. Fruit "parallel" code (your parallel) simply doesn't have this bonus. Ask Mark to explain it to you, at least he has seen it already.

I'm reading your second paragraph, excuse me whiel I pick myslef up off the floor. First mind-reading doesn't cut it. Second, you are applying Morton's fork now that you maybe finally understand the code. For you, it was the same (it wasn't of course) therefore he copied. Now, you realise it is very different, but, of course, now he copied and modified it. hahahahahahaha!!! Vas ls lost in all variations according to the brillient Hyatt logic. Same = copied. Different = copied and modified. So stupid, you expect anyone to believe your nonsense?

There is no code that even RECOGNIZES a "blocked pawn chain." Sorry. More made-up nonsense. And it is EASY to understand his intent. The code at hand is NOT intended to recognize a rook BEHIND enemy pawns. If it were, WHY would it care whether it had an own-pawn on the file at all or not? It does care, because it was designed to work EXACTLY as explained. Rook on half-open or open file. Vas changed one minor point, namely to call a file half-open if there are no friendly pawns in front of it. There are LOTS of things wrong with this idea. You have a pawn at e7, enemy pawn at e6, no other pawns on board. Is your rook useful on the e-file or not? Vas doesn't think so. It is simply obvious what his intent was, and it had nothing to do with your fertile imagination...

As far as this code, I have ALWAYS understood it. It is not exactly rocket science... Fruit has EXACTLY the same pair of bonuses, only it requires NO friendly pawns on the file for it to be considered half-open, while Rybka requires no friendly pawns in front of the rook. In 99% of the cases they are exactly the same, since for most of the game the rooks are generally found on the first or second rank.

And you talk about mind-reading in one sentence and come up with that "rook behind a blocked enemy pawn chain with a straight face?

Please show me THAT code.

My analysis is absolutely correct. I can't help it if you are so utterly confused. This is not an insult, this is the truth.

If you fail to analyse, or even see, at an incredibly simple level what Rybka is actually doing with this code, then any and all conclusions you come to will be nonsense.

Your points 1 and 2 above do NOT describe the action of the Rybka code. I am not going to discuss more complex functionality arising, with you, when you are wrong at such a simple level. What has happened to you, man? You used to at least read code accurately, in the past.

So it seems "imagination" is the correct term. There is no code that recognizes your "blocked pawn chain" anywhere in the code. Which I already knew before looking. My points 1 and 2 describe EXACTLY what the code does. EXACTLY. C code is, by definition, non-ambiguous. Be pretty useless otherwise.

haha!! this is almost funny if it weren't so sad that you have become so confused.

Your points 1 and 2 do NOT describe Rybka behaviour for this code. That you are so convinced you are right, when you are dead wrong, means that your subsequent "conclusions" are just so much garbage. GIGO for you, sad.

For the record, I never said "recognises blocked pawn chain", I said Rybka gives, in this code, the same thing that humans give, and the thing that Fruit does not give, the thing you don't understand. Rybka gives a bonus for getting round the back of the enemy pawn chain. It's a property of the code, but you need to understand a bit of chess to see it. You don't and you didn't and ckearly you still don't. Yet this forms one of the alleged "identical code" examples in your attack case. It's untrue, you and your investigators are clearly insufficiently skilled in chess to determine the creative originality in the Rybka code. Criminal.

[hyatt]

You said "this":

hahahahaha!! can you read ASM? find it yourself and work it out. Ridiculous question.There's a Rybka bonus (in the discussed code) for rook behind blocked enemy pawn chain, a common pattern.

"rybka bonus for rook behind blocked enemy pawn chain, a common pattern" But you didn't say that?

There is no such bonus. There is a bonus for being on a file in front of all pawns. Which would seem to be a bit silly with a white pawn on e7, white rook on e8, which is a KNOWN bad way to defend said pawn. But of course, his rule is "perfect" right? White gets to play without its rook, and probably lose that pawn quickly as well. Black puts his rook BEHIND said pawn and gets to use it normally.

It is pretty easy to see what he intended. The rook lift idea. But he didn't implement it very well and left a significant hold that was certainly unintentional. If there is a black pawn chain b7/c6/d5 I would certainly not move my rook off the open e file to get it behind that d5 pawn, and let black have the actual open e file while I busily attack a pawn I can't take. It is just a poorly written piece of code, with the intent as already explained, with the actual implementation having a fairly ugly mis-evaluation.

[Rebel]

Rybka is NOT "different here".

What

Zach and Mark admit that in their documents.

I think he has lost the plot. His comments are just ridiculous.

It's the same with for example this assumption / accusation:

Robert Hyatt: The well-known pawn values, used by almost everyone are (a) 100, (b) 128 (deep thought, etc, making it a power of 2 to allow divisions to be replaced by shifts; (c) 256, which makes it again a perfect power of 2. Why he [Vasik Rajlich] chose 3200 is unknown, and I won't speculate very much. But we do KNOW that he obfuscated the depth and node counts (is that a VIG statement or a pure statement of FACT, BTW?). So it is not unreasonable to assume that obfuscation played a part. [ answer ]

So while unraveling the Rybka secrets via RE they (Zach and/or Mark) came accross the observation Rybka uses the quite extraordinary pawn-value of 3200 in EVAL. Ooops thinks Bob, different than in Fruit. But Vas is guilty, has to be guilty, he copied Fruit, so what's the explanation? Aha, simply use the Fabien conjecture, it's an obfuscation (!!) to hide the Fruit origin and throw it into the public to incriminate Rybka. The world according to Bob is okay again.

While if Bob had paid attention he would had noticed that at the end of EVAL the score is shifted 5 bits resulting into the normal pawn-value of 100 or 1.00. And he 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) now in use by others because Zack and Mark offered their RE work for download at the ICGA-WIKI (it's still there) and on major chess sites such as Chessvibes. [ http://www.chessvibes.com/?q=reports/ry ... mpionships ]

In tunnel | VIG thinking 3200 means obfuscation as explanation for Bob, a bit thinking about the effects of the code reveals that a) EVAL will give better rounded 1.00 scores and b) likely it will produce more beta-cutoffs.

FACT - Rybka <> Fruit.

If the facts don't fit the theory, change the facts.
-- Albert Einstein

BTW Bob, do you still think Rybka's pawn value of 3200 is an obfuscation to hide the Fruit origins?

[hyatt]

Rybka is NOT "different here".

What

Zach and Mark admit that in their documents.

I think he has lost the plot. His comments are just ridiculous.

It's the same with for example this assumption / accusation:

Robert Hyatt: The well-known pawn values, used by almost everyone are (a) 100, (b) 128 (deep thought, etc, making it a power of 2 to allow divisions to be replaced by shifts; (c) 256, which makes it again a perfect power of 2. Why he [Vasik Rajlich] chose 3200 is unknown, and I won't speculate very much. But we do KNOW that he obfuscated the depth and node counts (is that a VIG statement or a pure statement of FACT, BTW?). So it is not unreasonable to assume that obfuscation played a part. [ answer ]

So while unraveling the Rybka secrets via RE they (Zach and/or Mark) came accross the observation Rybka uses the quite extraordinary pawn-value of 3200 in EVAL. Ooops thinks Bob, different than in Fruit. But Vas is guilty, has to be guilty, he copied Fruit, so what's the explanation? Aha, simply use the Fabien conjecture, it's an obfuscation (!!) to hide the Fruit origin and throw it into the public to incriminate Rybka. The world according to Bob is okay again.

While if Bob had paid attention he would had noticed that at the end of EVAL the score is shifted 5 bits resulting into the normal pawn-value of 100 or 1.00. And he 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) now in use by others because Zack and Mark offered their RE work for download at the ICGA-WIKI (it's still there) and on major chess sites such as Chessvibes. [ http://www.chessvibes.com/?q=reports/ry ... mpionships ]

In tunnel | VIG thinking 3200 means obfuscation as explanation for Bob, a bit thinking about the effects of the code reveals that a) EVAL will give better rounded 1.00 scores and b) likely it will produce more beta-cutoffs.

FACT - Rybka <> Fruit.

If the facts don't fit the theory, change the facts.
-- Albert Einstein

BTW Bob, do you still think Rybka's pawn value of 3200 is an obfuscation to hide the Fruit origins?

Please. YOU took something out of context. _I_ simply speculated on a possible explanation for something that was unexplained at the time. There is a world of difference between the two. My first statement had nothing to do with fruit. It was about the supposedly unused idea of rook in front of pawns, yet it had been used many times in the past.

what is the basis for your so-called "fact"? There is a LOT of basis for the statement that Rybka is non-original and was derived from Fruit.

YOU don't get to decide what is fact or not. A "fact" doesn't need to be decided, it is an incontrovertible truth.

As far as his pawn value goes, I don't know (emphasis on KNOW) the reason behind it, no. There is no rational/logical explanation for such an unusual number that NOBODY else uses. Of course, internally, he quashed the number back to a normal pawn value... which certainly makes it useless.

BTW you say "now in use by others." Who? Certainly not stockfish. Not me. I've got a dozen source programs on my macbook here that I use for testing opponents, I didn't find it in any of them. So "who" specifically?

[Chris Whittington]

You said "this":

hahahahaha!! can you read ASM? find it yourself and work it out. Ridiculous question.There's a Rybka bonus (in the discussed code) for rook behind blocked enemy pawn chain, a common pattern.

"rybka bonus for rook behind blocked enemy pawn chain, a common pattern" But you didn't say that?

There is no such bonus. There is a bonus for being on a file in front of all pawns. Which would seem to be a bit silly with a white pawn on e7, white rook on e8, which is a KNOWN bad way to defend said pawn. But of course, his rule is "perfect" right? White gets to play without its rook, and probably lose that pawn quickly as well. Black puts his rook BEHIND said pawn and gets to use it normally.

It is pretty easy to see what he intended. The rook lift idea. But he didn't implement it very well and left a significant hold that was certainly unintentional. If there is a black pawn chain b7/c6/d5 I would certainly not move my rook off the open e file to get it behind that d5 pawn, and let black have the actual open e file while I busily attack a pawn I can't take. It is just a poorly written piece of code, with the intent as already explained, with the actual implementation having a fairly ugly mis-evaluation.

To make it simple for you, common situation - two pawns on same file in opposition to other, not passed. We have three possibilities for a rook:

Both Fruit and Rybka give no bonus to the wR here, wR behind own pawn:
bp
..
..
wp
..
wR


Fruit gives no bonus to the rook here, we might assume the Rook came down an open file and swung over to attack the pawn from in front:
Rybka gives it a bonus (you call this half-open file bonus. Obviously it isn't). Humans would like the rook here too.
bp
..
wR
..
..
wP


Fruit gives no bonus to the Rook here. Again, we might assume the Rook came down an open file and swung across behind the pawn.
Rybka gives this a large bonus (erroneously, again, you call it open file bonus, obviously it isn't). Humans would do the same, they like this position a lot.
wR
..
bp
..
..
wp


So, now you can imagine a closed pawn position, one open file:
Fruit, with its rook-pawn code, likes to get on the open file, that's it.
Rybka with its rook-pawn code, like to get on the open, but it also likes most to get behind the enemy pawn chain.

The bonus for being BEHIND THE BLOCKED ENEMY PAWN CHAIN is an EMERGENT PROPERTY of the Rybka code. It's creative and original, qualitatively different to Fruit (or Crafty at the time, for that matter). But it was dismissed as unimportant. By investigators who clearly don't understand chess, they just understand code. Which is not enough. This chess code is NOT the same. It is not even open file/semi open file code, as you tried to shoehorn it into in desperate attempt to claim Fruit equivalence.
For rook-pawn endings, this Rybka code is a big boost.

Some other points you made:
"Badly implemented". Who cares, even if true? This is about whether Vas plagiariased Fruit. We are looking for disimilarities in chess code, not your idea of good/bad code.
"it is done by rook on 7th code." Who cares and so what? This is about plagiarised or not. Not your idea of how to program ideas.
"the effect is unintentional". Maybe to you. Which doesn't mean you can mind read it into his brain. I'ld imagine it was perfectly intentional, he is a smart programmer and understands chess way better than you do. But so what? It is what it is. A qualitatively different chess coding.
"you can construct positions where the code is not useful". Watkins "with a wp on a7 etc ..." Sure you can disrupt what is effectively a pattern recognition with fanciful patterns. The Rybka code is general purpose, and there are always exceptions. But this is another giant SO WHAT? for our purposes (did Vas plagiarise Fruit?), the question is whether there is or is not a qualitative difference. There is. So you can remove this section from the Zach paper, he got it all wrong, called it unimportant, and the Watkins paper, who also didn't seem to comprehend the effect and was convinced to shoehorn code that was NOT open file code, into Fruits open file model. So he could score it against Rybka. Unreasonable. Probably unconscious bias. Should not even be being compared together. Not same thing.

[Chris Whittington]

If you guys would stop removing context, even YOU might understand the statements...

I hope you are not referring to me here. I always quote your text in full, then reply. Ie I hit the "quote" button and append my comments. I leave your text entirely alone.
An apology would too much from you, I imagine?