FIDE Rules on ICGA - Rybka controversy

[hyatt]

lol Bob, I was actually WAITING you to come up with the compiler excuse.

It's an ASSUMPTION man, deal with it.

Give it up.

For once

You state it as a 100% incontrovertible fact, which it definitely is not.

I state it as a possible explanation, which it definitely is. I don't claim it is THE CORRECT explanation, however.

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

I thought about this overnight. I'll take that bet slightly reworded. YOU prove that he did NOT design the code as I speculated. I can hear the cluck-cluck noises already. Because now the onus would be on YOU. And it is an absolute certainty that you can't prove someone didn't so something. And NO, his word would NOT be proof.

Ah, the bet!! You want to do it, or just trying to pretend not to be big chicken? hahaha?

So, Hyatt makes some convoluted negation to the logic, where I am either quite lost in parsing, or too lazy to work out. In plain English what exactly are you proposing the bet to be? Is it balance of probabilities I have to exceed, or are you going to be so lacking in confidence you need beyond reasonable doubt, and what exactly is the proposal? It appears to be, "I need to prove that he did not copy the code and make an outright translation error" - right? On balance of probabilities? 51% It's irregular, because this assumes him guilty unless he can prove innocent, but that is Hyatt VIG bias all along, I suppose ....

Is that your bet? $25,000 or $50,000?





*

You want to make a lame bet that requires ME to prove something that can't be proven, and if I fail, you win. I proposed a REVERSAL. You get to try to prove something that can not possibly be proven either, and then YOU lose. I have no idea where that 51% nonsense came from, NOT from me however.

You can NOT prove that someone did NOT do something. You can't prove with 100% confidence that someone DID something. This is the type of bet that would lead to a never-ending argument, something _I_ am not willing to waste time on.

You just want to act infantile.

When does the "I triple-dog dare you" come into play??? (of course, according to the TV that would be a minor breach of etiquette as you should FIRST "double-dog dare me.")

You were the one proposing a "bet". I called your bluff. You want to change the terms of the bet. Bluff called again. Chicken out each time.

Right, so your position that Rybka rook-pawn code is a "bug created by mistranslation" is all just so much bullshit. Actually the code is smart, IM-smart and you and your gang of non chess programmers didn't see it. None of you were chess players, chess differences, huge chess differences just passed you by. Watkins,Zach and Hyatt.

Fine. I triple-dog dare you to go away and not come back. As far as what I believe concerning Rybka, the possible mis-translation is just an idea. A mistake _I_ made more than once in creating Crafty from a mailbox program. Whether it is right or not only ONE person on the planet knows. And from all his claims of originality that have been shown to be completely false, who would believe him if he did state what happened here?

then take the bet. all logic from your prose says: "take the bet". but you don't. Excuse me for calling your arguments bullshit. no money to back big mouth. it's trivial to disprove your assertion "bug, mistake when copying bla bla". don't believe it? take the bet ...... cluck cluck noises?

[Rebel]

lol Bob, I was actually WAITING you to come up with the compiler excuse.

It's an ASSUMPTION man, deal with it.

Give it up.

For once

You state it as a 100% incontrovertible fact, which it definitely is not.

I state it as a possible explanation, which it definitely is. I don't claim it is THE CORRECT explanation, however.

I deal with the facts the code is telling me, not with your VIG fantasies.

[Rebel]

I would say your 0.8 for the rook-pawn code is an outrageous mistake. And I'm being kind calling it a mistake.

Yup.

Let's consider the main message Zach and Mark uttered :

Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty, particularly when combined with the various other Fruit 2.1 bits that appear here-and-there in Rybka 1.0 Beta.

Zach Wegner: Simply put, Rybka's evaluation is virtually identical to Fruit's.

Then there are 2 ways to write an EVAL_COMP, the way Mark did, measuring the similarity between 8 engines, OR a SINGLE measuring between the 2 itself BASED on the accusation above. You get total different numbers.

Ain't that so?

No. Because then the question would be "how similar are others?" He tried to answer that. The PANEL folks that raised the issue made that suggestion. Otherwise you would be complaining "But we don't know how others fare when compared like this." And I do not see how you would get "totally different results". You get "more results" since there are more programs in the mix.

I don't know even where to begin what's wrong with EVAL_COMP. Here is minor yet real funny one.

Evaluation bishop pair. Watkins similarity is 0.3
Fruit - classic evaluation
Rybka - no code at all, it's pre calculated in the MIT (material imbalance table)

Meaning, IN THE LIGHT OF THE ACCUSATION Rybka's eval is (ahem) virtual indentical to Fruit --> 0.0 similarity.

[hyatt]

I would say your 0.8 for the rook-pawn code is an outrageous mistake. And I'm being kind calling it a mistake.

Yup.

Let's consider the main message Zach and Mark uttered :

Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty, particularly when combined with the various other Fruit 2.1 bits that appear here-and-there in Rybka 1.0 Beta.

Zach Wegner: Simply put, Rybka's evaluation is virtually identical to Fruit's.

Then there are 2 ways to write an EVAL_COMP, the way Mark did, measuring the similarity between 8 engines, OR a SINGLE measuring between the 2 itself BASED on the accusation above. You get total different numbers.

Ain't that so?

No. Because then the question would be "how similar are others?" He tried to answer that. The PANEL folks that raised the issue made that suggestion. Otherwise you would be complaining "But we don't know how others fare when compared like this." And I do not see how you would get "totally different results". You get "more results" since there are more programs in the mix.

I don't know even where to begin what's wrong with EVAL_COMP. Here is minor yet real funny one.

Evaluation bishop pair. Watkins similarity is 0.3
Fruit - classic evaluation
Rybka - no code at all, it's pre calculated in the MIT (material imbalance table)

Meaning, IN THE LIGHT OF THE ACCUSATION Rybka's eval is (ahem) virtual indentical to Fruit --> 0.0 similarity.

So if A counts the bishops and says ">1 is good", and B looks that up in a table that says ">1 is good" those are fundamentally different? I've already pointed out the hole in that, but here goes, once again.

Crafty count's mobility in a non-traditional way, where each square attacked is NOT weighted equally. There used to be code in the evaluation that would (a) generate bishop attacks; (b) extract an equally-weighted set of squares from that and add to total; (c) repeat for the next set of equally weighted squares, until all are done.

Today, rather than generating the bishop moves, I do a magic lookup into a table where these squares have already been summed, weighted and totaled. I get EXACTLY the same number for the same position, using either approach. The last takes almost no time, however.

Are those "fundamentally different"? I don't think so. If someone uses a pawn hash, is that fundamentally different from someone that doesn't, even if their pawn evaluation matches exactly other than that? I don't think so.

Your definition of "fundamentally different" is "fundamentally flawed."

[Chris Whittington]

I would say your 0.8 for the rook-pawn code is an outrageous mistake. And I'm being kind calling it a mistake.

Yup.

Let's consider the main message Zach and Mark uttered :

Mark Watkins: I think the case for "copyright infringement" (or plagiarism) of the evaluation function as a whole is quite weighty, particularly when combined with the various other Fruit 2.1 bits that appear here-and-there in Rybka 1.0 Beta.

Zach Wegner: Simply put, Rybka's evaluation is virtually identical to Fruit's.

Then there are 2 ways to write an EVAL_COMP, the way Mark did, measuring the similarity between 8 engines, OR a SINGLE measuring between the 2 itself BASED on the accusation above. You get total different numbers.

Ain't that so?

No. Because then the question would be "how similar are others?" He tried to answer that. The PANEL folks that raised the issue made that suggestion. Otherwise you would be complaining "But we don't know how others fare when compared like this." And I do not see how you would get "totally different results". You get "more results" since there are more programs in the mix.

I don't know even where to begin what's wrong with EVAL_COMP. Here is minor yet real funny one.

Evaluation bishop pair. Watkins similarity is 0.3
Fruit - classic evaluation
Rybka - no code at all, it's pre calculated in the MIT (material imbalance table)

Meaning, IN THE LIGHT OF THE ACCUSATION Rybka's eval is (ahem) virtual indentical to Fruit --> 0.0 similarity.

So if A counts the bishops and says ">1 is good", and B looks that up in a table that says ">1 is good" those are fundamentally different? I've already pointed out the hole in that, but here goes, once again.

Crafty count's mobility in a non-traditional way, where each square attacked is NOT weighted equally. There used to be code in the evaluation that would (a) generate bishop attacks; (b) extract an equally-weighted set of squares from that and add to total; (c) repeat for the next set of equally weighted squares, until all are done.

Today, rather than generating the bishop moves, I do a magic lookup into a table where these squares have already been summed, weighted and totaled. I get EXACTLY the same number for the same position, using either approach. The last takes almost no time, however.

Are those "fundamentally different"? I don't think so. If someone uses a pawn hash, is that fundamentally different from someone that doesn't, even if their pawn evaluation matches exactly other than that? I don't think so.

Your definition of "fundamentally different" is "fundamentally flawed."

The bishop pair is a well known chess heuristic. It says "2 bishops is good" and better than "1 bishop" or "0 bishop". Therefore chess programmer, he count bishops and say if count>1 then bonus.

You are aware that copyright law and obviously by extension via extraction all the way up to the imaginary "ideas law" via "plagiarism law", holds that there are many cases where identical/similar code/expressions are NOT copyright breaches (by extension not plagiarism, nor ideas breaches)? In this case the COUNTING is effectively: a) public domain and b) very simple and c) the best way, if not the only way. Therefore, copyright law (extend to plagiarism and ideas) says FILTER this one OUT. We can't consider it.

When you add that the concepts are coded COMPLETELY DIFFERENTLY in R and F then the question arises: WTF are you even thinking about this? Pass it. Next code segment ...

Obviously though, it is very convenient and nice for you to include it is the "similarity list", because by then everybody should have forgotten that it should have been filtered out. So you get one more point against Vas than you should do, and it all adds up. You can't add apples and oranges to get a count of oranges, any more than you can "possibly copied similarities" to "similar things that are filtered out and not counting as copied" to get a count of possible copied similarities. It's called CHEATING.

Re Crafty. Who cares what you do? Neither Fruit nor Rybka carry out your convoluted tinkering around on mobility code (-600 ELO additive), they just do a quick and dirty mobility count, the same as everybody with a YOUNG program. Tinkering comes much later, by loser programmers who can't understand their -600 ELO failures. The loser programs then have a huge "original" component list brought about by tinkering in desperation for those elusive ELO points.

Basic, quick, dirty, mobility should also be filtered. It"'s public domain and a well known formula. Can't be copied. Shouldn't be included in the "copied" list. But, of course, it is very convenient for you to include yet another "supposed to be filtered out", non-copy case because it all adds up, and then everybody forgets you added apples and oranges and you can create a 6 sigma outlier with 1 in 100000000000 gazillion alleged chance of not being copied and make a pretty graphic for icga to put in its report. MISLEADING. Also basically a CHEAT.

[Rebel]

Wasn't the topic the evaluation of the bishop pair?

What's the similarity between Fruit and Rybka?

Where is that 0.3 coming from?

[Chris Whittington]

Wasn't the topic the evaluation of the bishop pair?

What's the similarity between Fruit and Rybka?

Where is that 0.3 coming from?

Some programs are more "not equal" than others. hahahahahaha!!!

with a list of 8 programs to pair up, all the researcher need to do is find a pair which are so hacked around with the usual find-ELO desperations that the differences and stupidities zoom off into the stratosphere - and call that 0.0; then all the other pairs have to have raised numbers, even though they are still different, they are not insanely different. Hence some programs are more "not equal" than others.

"more not equal" maps to using values like 0.3 or 0.5, these are all just magical guesses for "not equal" but, eg, Faile and Crappy pair were even more "not equal" so they got the 0.0. Then we get the MAGIC TRICK. "degree of not equal" becomes "degree of similarity". hahahahaha!! clever, no? Thus two "not equal" programs are registered as "similar", and possibly "plagiarised".

[Rebel]

Wasn't the topic the evaluation of the bishop pair?

What's the similarity between Fruit and Rybka?

Where is that 0.3 coming from?

Some programs are more "not equal" than others. hahahahahaha!!!

with a list of 8 programs to pair up, all the researcher need to do is find a pair which are so hacked around with the usual find-ELO desperations that the differences and stupidities zoom off into the stratosphere - and call that 0.0; then all the other pairs have to have raised numbers, even though they are still different, they are not insanely different. Hence some programs are more "not equal" than others.

"more not equal" maps to using values like 0.3 or 0.5, these are all just magical guesses for "not equal" but, eg, Faile and Crappy pair were even more "not equal" so they got the 0.0. Then we get the MAGIC TRICK. "degree of not equal" becomes "degree of similarity". hahahahaha!! clever, no? Thus two "not equal" programs are registered as "similar", and possibly "plagiarised".

Yep, with 8 engines to compare numbers have to correlate in order to make sense, in a direct compare the only thing that counts is Rybka <> Fruit at an exact understanding what the code actually evaluates, whole different game.

[Chris Whittington]

Wasn't the topic the evaluation of the bishop pair?

What's the similarity between Fruit and Rybka?

Where is that 0.3 coming from?

Some programs are more "not equal" than others. hahahahahaha!!!

with a list of 8 programs to pair up, all the researcher need to do is find a pair which are so hacked around with the usual find-ELO desperations that the differences and stupidities zoom off into the stratosphere - and call that 0.0; then all the other pairs have to have raised numbers, even though they are still different, they are not insanely different. Hence some programs are more "not equal" than others.

"more not equal" maps to using values like 0.3 or 0.5, these are all just magical guesses for "not equal" but, eg, Faile and Crappy pair were even more "not equal" so they got the 0.0. Then we get the MAGIC TRICK. "degree of not equal" becomes "degree of similarity". hahahahaha!! clever, no? Thus two "not equal" programs are registered as "similar", and possibly "plagiarised".

Yep, with 8 engines to compare numbers have to correlate in order to make sense, in a direct compare the only thing that counts is Rybka <> Fruit at an exact understanding what the code actually evaluates, whole different game.

Yes, cunning. That was your spot. Credit to Ed for the non-obvious mathematical intuition.