FIDE Rules on ICGA - Rybka controversy

[Chris Whittington]

It was not "new and creative". And it was not "just done by Bob". John was also doing it at the SAME time.

You are certainly making up "new and creative". A rook lift was not uncommon at all. You can even find that mentioned in Hsu's book about deep blue. Along with things like moving a rook to a file that is likely to become open soon, even though it is not seen happening by the search. Might be new to you. Not a new idea to me. And, BTW, a rook on such a "pseudo-half-open file" is NOT as good as a rook on a real open file.

You should stop stating things that are NOT true, such as the "rook behind enemy pawns" that does not exist. Sometimes it would seem that your typing gets way ahead of reality, and you don't stop to check your facts, ever. This is one such place where that would have saved your having to once again backtrack. Just as with Ed's repeatedly claiming the ICGA had posted all of the Vas emails. I only looked on the Wiki and did not see them. I did not think to further check (Mark did however) to see if something had been removed. I just assumed that must have happened since Ed was 100% certain they were posted there. Guess what? They weren't. Again it would be nice to have some actual fact-checking going on in parallel with fingers-pecking-on-the-keyboard. It is bad enough to have to argue about REAL evidence or circumstances, it is much worse to argue about things that don't exist like the rook behind enemy pawns or posts that were never posted, etc...

Fascinating number of sideways tangents. Are you uanble to stick to answering the real point?

Rybka rook-pawn code has a substantially different and better patten recognition than Fruit and you did NOT recognise it, claiming instead equivalence, and calling it what it was not, namely open/half open file code. It was NOT open and half open file code. You said it was to try and FORCE it into some parallel with Fruit that does NOT exist.

[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.

[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?

[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.

[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.

[Rebel]

it becomes Vas verbatim copied Fruit (the real accusation) ...

Let's review Fabien's accusation ...

this is my conjecture ...

There is a difference between a "real accusation" and a "conjecture" -- capiche? Letouzey (effectively) accused Rajlich of copying Fruit with different words, and he conjectured that this was likely done in a fairly explicit manner. Similarly with many of the other programmers that signed the open letter. If you are lazy with the meaning of words, the discussion becomes nonsensical.

Read the complete email conversation, it's what Fabien believed. Perception is all. In the hypothetical case this would go to court and each of the 16 programmers who signed the Fabien letter would be questioned under oath about their beliefs if Vas verbatim copied Fruit or that it ONLY JUST was about rule #2 then, well, any average lawyer would get the truth. Maybe even from you? I might assume when you started your crusade against Vas in his forum (2008, or was it 2007?) you didn't do that because you had rule #2 in mind, correct? The rule #2 idea to punish Vas via the ICGA was from 2011.

But again, let's drop it, we will never agree on this one and by your express wish focus on rule #2 instead,

What the hell does rule #2 mean?

Each program must be the original work of the entering developers.

So far so good. Much in agreement. And one would expect the definition of an original work to meet the changed landscape and developments but it doesn't. Internet changed everything starting in the mid 90's. Programmers started to talk to each other in email, fora, exchanging ideas, some even put their code on the web. An explosion of knowledge was the result followed by rapid progress. But the ICGA didn't adapt to the new situation, in fact they became an obstacle to progress. After the verdict (and how rule #2 possibly can be interpreted) a programmer is left with the dilemma:

Shall I study open sources and gather knowledge? Tricky, the risk is too high I am influenced too much by it.

Or...

Shall study open sources just to make sure I don't have anything similar to them in my own code, just in case the ICGA is tempted to peek in my binary?

Sh.., whatever I do I am busted.

Such thinking blocks progress. Surely there are better ways to fight cloning.

Hint: CSVN.

[Rebel]

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

[Rebel]

Rybka is NOT "different here".

What

Zach and Mark admit that in their documents.

[Chris Whittington]

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.

[Chris Whittington]

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.