FIDE Rules on ICGA - Rybka controversy

[hyatt]

That was not a chess lesson. It was "RE nonsense". If you read what he wrote, he SPECIFICALLY discussed the difference between a bit board implementation and a mailbox implementation. Something we said we EXPLICITLY abstracted away. A loop vs an AND mask? Bit board vs mailbox, nothing more, nothing less.

So please don't call that a "lesson" to someone who actually teaches programming. That was more of a "chess obfuscation" than anything else. Zach did it exactly right there. I don't think much of the "seems to be, or appears to be" nonsense. It is or it isn't.

Your question two posts back in that thread is also nonsensically phrased. You snipped just the 4 bit-wise ANDs (tst instructions) and left out the rest. You DID realize that the masks and stuff were loaded at the top of the code? You seem almost surprised that some rather convoluted mailbox code collapses into 4 AND operations in a bit board program. This is quite common. I've used the term "bit-parallel" because bit boards let me ask a question with one AND that would take a loop with multiple if-statements inside in a mailbox program. That's part of the attractiveness of bit boards for those of us that decided to invest the time to get comfortable with them.

And you are missing it again, you only look at the code and not what the code does. If you had read Marcel carefully you would had seen Fruit and Rybka are evaluating different, Fruit has the exception code for second ranked pawns that can advance 2 squares. Rybka has not, just a quick and dirty evaluation. Fabien uses the Kmoch definition, Vas not. Does the name Hans Kmoch and his basic stuff about pawns every chess player needs to know mean anything anythng to you? There is even a whole page on the CPW about him.

You see, there is this pattern, you ASM geeks (of which I belong too) only look at the code and shout EUREKA!, this piece of Rybka code smells to similarity with Fruit and then you forget to look what the code actually evaluates, as in this case.

So my statement still stands:

COMP EVAL fails to mention that EVERY eval ingrediënt in Fruit and Rybka is coded DIFFERENTLY even after substraction of the Mailboard / Bitboard differences.

Next one?

You miss MY point. Do you know why Rybka doesn't do that? Not so convenient in bitmaps. A pretty natural part of conversion from one to the other. I had several such things that were in Cray Blitz but which I left out of Crafty because (a) it was not clear if they were really beneficial and (b) it was more complicated (affecting speed) to do it the same way. Taking both of those into consideration...

BTW we didn't say "smells to similarity." We said "they do the same thing" or in a few cases "almost exactly the same thing but there is one difference."

The rook scoring (open/half-open files) is a good example. I'd bet that was an outright error in translation, seeing as how it is actually a -25 Elo change.

If you want to hang on to that "every" simply because the code doesn't match, and it obviously could NOT match when using two different board representations" then that's up to you. I know better.

[Chris Whittington]

That was not a chess lesson. It was "RE nonsense". If you read what he wrote, he SPECIFICALLY discussed the difference between a bit board implementation and a mailbox implementation. Something we said we EXPLICITLY abstracted away. A loop vs an AND mask? Bit board vs mailbox, nothing more, nothing less.

So please don't call that a "lesson" to someone who actually teaches programming. That was more of a "chess obfuscation" than anything else. Zach did it exactly right there. I don't think much of the "seems to be, or appears to be" nonsense. It is or it isn't.

Your question two posts back in that thread is also nonsensically phrased. You snipped just the 4 bit-wise ANDs (tst instructions) and left out the rest. You DID realize that the masks and stuff were loaded at the top of the code? You seem almost surprised that some rather convoluted mailbox code collapses into 4 AND operations in a bit board program. This is quite common. I've used the term "bit-parallel" because bit boards let me ask a question with one AND that would take a loop with multiple if-statements inside in a mailbox program. That's part of the attractiveness of bit boards for those of us that decided to invest the time to get comfortable with them.

And you are missing it again, you only look at the code and not what the code does. If you had read Marcel carefully you would had seen Fruit and Rybka are evaluating different, Fruit has the exception code for second ranked pawns that can advance 2 squares. Rybka has not, just a quick and dirty evaluation. Fabien uses the Kmoch definition, Vas not. Does the name Hans Kmoch and his basic stuff about pawns every chess player needs to know mean anything anythng to you? There is even a whole page on the CPW about him.

You see, there is this pattern, you ASM geeks (of which I belong too) only look at the code and shout EUREKA!, this piece of Rybka code smells to similarity with Fruit and then you forget to look what the code actually evaluates, as in this case.

So my statement still stands:

COMP EVAL fails to mention that EVERY eval ingrediënt in Fruit and Rybka is coded DIFFERENTLY even after substraction of the Mailboard / Bitboard differences.

Next one?

You miss MY point. Do you know why Rybka doesn't do that? Not so convenient in bitmaps. A pretty natural part of conversion from one to the other. I had several such things that were in Cray Blitz but which I left out of Crafty because (a) it was not clear if they were really beneficial and (b) it was more complicated (affecting speed) to do it the same way. Taking both of those into consideration...

BTW we didn't say "smells to similarity." We said "they do the same thing" or in a few cases "almost exactly the same thing but there is one difference."

The rook scoring (open/half-open files) is a good example. I'd bet that was an outright error in translation, seeing as how it is actually a -25 Elo change.

If you want to hang on to that "every" simply because the code doesn't match, and it obviously could NOT match when using two different board representations" then that's up to you. I know better.

Bet taken. $25,000 that you can't prove beyond any reasonable doubt that the Rybka rook-pawn code we were discussing was a "outright error in translation" within the next two months. I'll send you my lawyers address, we can both deposit $25,000 each. The $50,000 goes to me when you lose, else vice versa.

I can hear the cluck-cluck noises already.

[hyatt]

That was not a chess lesson. It was "RE nonsense". If you read what he wrote, he SPECIFICALLY discussed the difference between a bit board implementation and a mailbox implementation. Something we said we EXPLICITLY abstracted away. A loop vs an AND mask? Bit board vs mailbox, nothing more, nothing less.

So please don't call that a "lesson" to someone who actually teaches programming. That was more of a "chess obfuscation" than anything else. Zach did it exactly right there. I don't think much of the "seems to be, or appears to be" nonsense. It is or it isn't.

Your question two posts back in that thread is also nonsensically phrased. You snipped just the 4 bit-wise ANDs (tst instructions) and left out the rest. You DID realize that the masks and stuff were loaded at the top of the code? You seem almost surprised that some rather convoluted mailbox code collapses into 4 AND operations in a bit board program. This is quite common. I've used the term "bit-parallel" because bit boards let me ask a question with one AND that would take a loop with multiple if-statements inside in a mailbox program. That's part of the attractiveness of bit boards for those of us that decided to invest the time to get comfortable with them.

And you are missing it again, you only look at the code and not what the code does. If you had read Marcel carefully you would had seen Fruit and Rybka are evaluating different, Fruit has the exception code for second ranked pawns that can advance 2 squares. Rybka has not, just a quick and dirty evaluation. Fabien uses the Kmoch definition, Vas not. Does the name Hans Kmoch and his basic stuff about pawns every chess player needs to know mean anything anythng to you? There is even a whole page on the CPW about him.

You see, there is this pattern, you ASM geeks (of which I belong too) only look at the code and shout EUREKA!, this piece of Rybka code smells to similarity with Fruit and then you forget to look what the code actually evaluates, as in this case.

So my statement still stands:

COMP EVAL fails to mention that EVERY eval ingrediënt in Fruit and Rybka is coded DIFFERENTLY even after substraction of the Mailboard / Bitboard differences.

Next one?

You miss MY point. Do you know why Rybka doesn't do that? Not so convenient in bitmaps. A pretty natural part of conversion from one to the other. I had several such things that were in Cray Blitz but which I left out of Crafty because (a) it was not clear if they were really beneficial and (b) it was more complicated (affecting speed) to do it the same way. Taking both of those into consideration...

BTW we didn't say "smells to similarity." We said "they do the same thing" or in a few cases "almost exactly the same thing but there is one difference."

The rook scoring (open/half-open files) is a good example. I'd bet that was an outright error in translation, seeing as how it is actually a -25 Elo change.

If you want to hang on to that "every" simply because the code doesn't match, and it obviously could NOT match when using two different board representations" then that's up to you. I know better.

Bet taken. $25,000 that you can't prove beyond any reasonable doubt that the Rybka rook-pawn code we were discussing was a "outright error in translation" within the next two months. I'll send you my lawyers address, we can both deposit $25,000 each. The $50,000 goes to me when you lose, else vice versa.

I can hear the cluck-cluck noises already.

We both lose. HOW do you prove such? You can't even ask the principal here.

Or do you believe "the world's greatest programmer actually intentionally designed something that COST him 25 Elo???

[Chris Whittington]

That was not a chess lesson. It was "RE nonsense". If you read what he wrote, he SPECIFICALLY discussed the difference between a bit board implementation and a mailbox implementation. Something we said we EXPLICITLY abstracted away. A loop vs an AND mask? Bit board vs mailbox, nothing more, nothing less.

So please don't call that a "lesson" to someone who actually teaches programming. That was more of a "chess obfuscation" than anything else. Zach did it exactly right there. I don't think much of the "seems to be, or appears to be" nonsense. It is or it isn't.

Your question two posts back in that thread is also nonsensically phrased. You snipped just the 4 bit-wise ANDs (tst instructions) and left out the rest. You DID realize that the masks and stuff were loaded at the top of the code? You seem almost surprised that some rather convoluted mailbox code collapses into 4 AND operations in a bit board program. This is quite common. I've used the term "bit-parallel" because bit boards let me ask a question with one AND that would take a loop with multiple if-statements inside in a mailbox program. That's part of the attractiveness of bit boards for those of us that decided to invest the time to get comfortable with them.

And you are missing it again, you only look at the code and not what the code does. If you had read Marcel carefully you would had seen Fruit and Rybka are evaluating different, Fruit has the exception code for second ranked pawns that can advance 2 squares. Rybka has not, just a quick and dirty evaluation. Fabien uses the Kmoch definition, Vas not. Does the name Hans Kmoch and his basic stuff about pawns every chess player needs to know mean anything anythng to you? There is even a whole page on the CPW about him.

You see, there is this pattern, you ASM geeks (of which I belong too) only look at the code and shout EUREKA!, this piece of Rybka code smells to similarity with Fruit and then you forget to look what the code actually evaluates, as in this case.

So my statement still stands:

COMP EVAL fails to mention that EVERY eval ingrediënt in Fruit and Rybka is coded DIFFERENTLY even after substraction of the Mailboard / Bitboard differences.

Next one?

You miss MY point. Do you know why Rybka doesn't do that? Not so convenient in bitmaps. A pretty natural part of conversion from one to the other. I had several such things that were in Cray Blitz but which I left out of Crafty because (a) it was not clear if they were really beneficial and (b) it was more complicated (affecting speed) to do it the same way. Taking both of those into consideration...

BTW we didn't say "smells to similarity." We said "they do the same thing" or in a few cases "almost exactly the same thing but there is one difference."

The rook scoring (open/half-open files) is a good example. I'd bet that was an outright error in translation, seeing as how it is actually a -25 Elo change.

If you want to hang on to that "every" simply because the code doesn't match, and it obviously could NOT match when using two different board representations" then that's up to you. I know better.

Bet taken. $25,000 that you can't prove beyond any reasonable doubt that the Rybka rook-pawn code we were discussing was a "outright error in translation" within the next two months. I'll send you my lawyers address, we can both deposit $25,000 each. The $50,000 goes to me when you lose, else vice versa.

I can hear the cluck-cluck noises already.

We both lose. HOW do you prove such? You can't even ask the principal here.

Or do you believe "the world's greatest programmer actually intentionally designed something that COST him 25 Elo???

hahahaha!! not exactly difficult turning Hyatt into giant clucking chicken.

Bet is still on, I can prove it. Still want to run away, clucketty-cluck?! Speak now or shut up. Make it $50,O00 if you are so sure of yourself. Well, Hyatt?

On the code, it is qualitatively and quantitatively different, but your gang of witch-hunting, Vas-hating cheaters decided that they had to shoehorn the Vas code into the Fruit model, when it is NOT EVEN open semi-open file code. Fraudulently putting qualitatively and quantitatively different code under the same headings. Outrageous.

Your arguments about ELO, bugs, bad code blah-di-blah are so much hot air. For the purposes of whether the code was copied or not, entirely irrelevent. The question is if the code is quantitatively and qualitatively different or not. Not how badly/well it is written.

Finally, you ELO calculations using your own program are rejected. Who cares what you can or can't get Crafty to do?

[hyatt]

Not exactly difficult to prove you are an absolute moron, either. How can we PROVE how Vas developed something? You got a DeLorean + flux capacitor handy so we can go back and watch. Otherwise NO proof is possible. Your silly name-calling and usual infantile "wanna bet?" does nothing but make you look exactly like what you are.

For the Elo test, learn to read. I did the SAME thing to Fruit, and got a similar BIG Elo drop. So two for two is pretty convincing for me. Both of those programs are quite strong.

So today you do nothing but waste time posting complete "nothing". How typical.

I don't care what YOU reject at all, since your rejecting something suggest it is good, and vice-versa.

[Rebel]

I'm not going to go through every eval term, but for 1.0 beta, the above is certainly NOT true. One example is isolated pawns, and by factoring out the bitboard/mailbox differences, you are left with identical implementations. A simple one, agreed, but you said EVERY one is coded differently, and showing one exception is enough to break that statement.

Nope. You have forgotten Marcel's chess lesson. [ http://rybkaforum.net/cgi-bin/rybkaforu ... #pid396062 ] Something for Mark as well since it's about his COMP-EVAL document.

The given link demonstrates that backward pawns (arguably the most complicated and quirky pawn factor) are indeed different in definition (and other ways). Which marcelk notes was already apparent in EVAL_COMP. The post says nothing about the "coding" (at any abstraction level) of any other eval features. [And as hyatt points out, the implementation of backward pawns a la Kmoch can be encumbered when using bitboards as opposed to mailbox].

I disagree with your logic. You can't use Rybka's main defence, a different data structure (bit-board), against Rybka to explain another difference. The code does (evaluates) different things. Thus Rybka <> Fruit.

Let's sort this out first before going further. It's quite fundamental and a repeating theme.

[hyatt]

I'm not going to go through every eval term, but for 1.0 beta, the above is certainly NOT true. One example is isolated pawns, and by factoring out the bitboard/mailbox differences, you are left with identical implementations. A simple one, agreed, but you said EVERY one is coded differently, and showing one exception is enough to break that statement.

Nope. You have forgotten Marcel's chess lesson. [ http://rybkaforum.net/cgi-bin/rybkaforu ... #pid396062 ] Something for Mark as well since it's about his COMP-EVAL document.

The given link demonstrates that backward pawns (arguably the most complicated and quirky pawn factor) are indeed different in definition (and other ways). Which marcelk notes was already apparent in EVAL_COMP. The post says nothing about the "coding" (at any abstraction level) of any other eval features. [And as hyatt points out, the implementation of backward pawns a la Kmoch can be encumbered when using bitboards as opposed to mailbox].

I disagree with your logic. You can't use Rybka's main defence, a different data structure (bit-board), against Rybka to explain another difference. The code does (evaluates) different things. Thus Rybka <> Fruit.

Let's sort this out first before going further. It's quite fundamental and a repeating theme.

A single difference does NOT make the programs different.

[Rebel]

I'm not going to go through every eval term, but for 1.0 beta, the above is certainly NOT true. One example is isolated pawns, and by factoring out the bitboard/mailbox differences, you are left with identical implementations. A simple one, agreed, but you said EVERY one is coded differently, and showing one exception is enough to break that statement.

Nope. You have forgotten Marcel's chess lesson. [ http://rybkaforum.net/cgi-bin/rybkaforu ... #pid396062 ] Something for Mark as well since it's about his COMP-EVAL document.

The given link demonstrates that backward pawns (arguably the most complicated and quirky pawn factor) are indeed different in definition (and other ways). Which marcelk notes was already apparent in EVAL_COMP. The post says nothing about the "coding" (at any abstraction level) of any other eval features. [And as hyatt points out, the implementation of backward pawns a la Kmoch can be encumbered when using bitboards as opposed to mailbox].

I disagree with your logic. You can't use Rybka's main defence, a different data structure (bit-board), against Rybka to explain another difference. The code does (evaluates) different things. Thus Rybka <> Fruit.

Let's sort this out first before going further. It's quite fundamental and a repeating theme.

A single difference does NOT make the programs different.

I am glad you understand my point.

And as an addition, the Kmoch definition of a backward pawn as practiced by Fabien in Fruit (IMO) isn't found in many programs, I am not aware of one who has it in use. Therefore if it were in Rybka it would have been a huge red flag. But it isn't there and shouldn't have been counted as evidence with a 0.7 similarity to Fruit (on a scale of 1.0) in Mark's document. Considering the absence of an unique Fruit eval feature IN THE LIGHT OF THE ACCUSATION Rybka=Fruit the similarity with Rybka is exactly 0.0.

A second case would be the evaluation of double-pawn rewarded by Mark with an 1.0 similarity, so the suggestion for the reader is that Rybka=Fruit. Evaluation of a double pawn is one of the most simple ingredients of EVAL. Most programs simply penalizes double pawns with a fixed value and that's it. So does Fruit. The better EVAL's (Fruit included) make a distinction with the material on the board and penalize a double pawn more in the endgame. But I haven't seem a program that gives NO PENALTY AT ALL for any double pawn in the middle game and only in the endgame. This is so fundamentally different IN THE LIGHT OF THE ACCUSATION Rybka=Fruit the similarity with Rybka is exactly 0.0.

Code is also different -

Code: Select all

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

There is NO midgame code in Rybka.

A third case...................

[Rebel]

Do I need to read the other previous 60 posts, or is this a sufficient résumé?

I believe it where 120

But as for an answer, no, do as you please, it's very time consuming, so I understand if you don't.

But I have 2 wishes.

1. Your discussion with Chris about rook evaluation [ http://www.open-chess.org/viewtopic.php?p=21744#p21744 ]. I am curious if the two of you can reach a consensus over this. It's one thing to look at code similarity at abstraction level and another thing to look at what the code actually evaluates. Crucial in the phase in which we are now in.

2. My hypothesis of what really happened [ http://www.open-chess.org/viewtopic.php?p=21759#p21759 ]

I haven't been posting here since 1½-2 years (or so) and then I saw the FIDE EC verdict discussed here and joined. Of course the inevitabe happened and the technical stuff became an issue once again. And I thought it would be nice to hear from you if during that 1½-2 years opinions have changed a bit, say 5-10-15%. Mine certainly have, so hence my curiosity to hear your point of view on (2).

[Rebel]

About candidates:
1. Mark suggested Jonathan. While he is a great and knowledgable guy I would first like to know if he kept up with CC and how it developed especially how internet has affected (or shall I say infected) CC. In the old days they could bicker and fight over the use of ideas. We laugh about that nowadays. So Jonathan will need to have a good understanding how programmers nowadays think. In case he didn't keep up than I would prefer Mark instead. Not sure if Vas would like that but I could lobby for it.
2. Chrilly. Okay, I understand he left. Doesn't mean I could try to persuade him.

Given that Lukas Cimotti (arguably the closest person to VR) accused me of being behind IPPOLIT (in the wake of my R3/IPPOLIT writings),

Someone pointed me at that thread and Vas (although not naming you by name) wasn't exactly friendly about you also. But then again you were sort of documenting his work, It's like someone breaking into your house, stealing the jewelry and table silver. Of course the (Lukas) accusation was a ridiculous one, there is a much better candidate and he had a motive too.

On the other hand realize that many have the ability to RE, not of those many have the needed passion for it and together that leaves only a few candidates when it's about RE a computer chess program. And you are one of them, that you have obviously proven. And so your name circulates as a logical candidate. Not my view. But I already said that.

I really don't think I would be a good choice.

Well, I think you are, I give you that credit.

And there is some irony in the idea too, atonement and redemption!

Also, I would only agree to do it if the purpose were to validate an actual entry by Rajlich into an event (either ICGA, CSVN, or otherwise).

Understood.