FIDE Rules on ICGA - Rybka controversy

[marcelk]

The CSVN uses a small checklist for inspections. This is mentioned in the checklist.

Good to know you have at least 2 checklists

Better than having none.

[Harvey Williamson]

The CSVN uses a small checklist for inspections. This is mentioned in the checklist.

Good to know you have at least 2 checklists

Better than having none.

LOL agreed!

[Rebel]

in where you fail to mention that EVERY eval ingrediënt between Fruit and Rybka is coded DIFFERENTLY.

This is an utterly irrelevant point. It is trivial that a bitboard engine will be coded "DIFFERENTLY" than a mailbox engine.

It's an indication Mark of the low level our discussion has sank. I would expect such a comment from Bob and thus preemptive adding "after deducting BB|MB" whenever I reply to him. But you now too

Now I need to become as prissy as you and add self understood stuff? You knew very well what I meant.

So lemme repeat -

In your COMP EVAL you fail to mention that EVERY eval ingrediënt between Fruit and Rybka is coded DIFFERENTLY after substraction of the Mailboard / Bitboard differences.

[hyatt]

in where you fail to mention that EVERY eval ingrediënt between Fruit and Rybka is coded DIFFERENTLY.

This is an utterly irrelevant point. It is trivial that a bitboard engine will be coded "DIFFERENTLY" than a mailbox engine.

It's an indication Mark of the low level our discussion has sank. I would expect such a comment from Bob and thus preemptive adding "after deducting BB|MB" whenever I reply to him. But you now too

Now I need to become as prissy as you and add self understood stuff? You knew very well what I meant.

So lemme repeat -

In your COMP EVAL you fail to mention that EVERY eval ingrediënt between Fruit and Rybka is coded DIFFERENTLY after substraction of the Mailboard / Bitboard differences.

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.

[Rebel]

in where you fail to mention that EVERY eval ingrediënt between Fruit and Rybka is coded DIFFERENTLY.

This is an utterly irrelevant point. It is trivial that a bitboard engine will be coded "DIFFERENTLY" than a mailbox engine.

It's an indication Mark of the low level our discussion has sank. I would expect such a comment from Bob and thus preemptive adding "after deducting BB|MB" whenever I reply to him. But you now too

Now I need to become as prissy as you and add self understood stuff? You knew very well what I meant.

So lemme repeat -

In your COMP EVAL you fail to mention that EVERY eval ingrediënt between Fruit and Rybka is coded DIFFERENTLY after substraction of the Mailboard / Bitboard differences.

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.

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

[Rebel]

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?

[BB+]

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

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.

Perhaps I still misinterpret what "coded differently" means, but I think this statement is simply fallacious. Here are some examples.

• Blocked bishops: Fruit 2.1 and Rybka 1.0 Beta require wBc1/wPd2 and some unit on d3, and penalise the bishop.
• Fruit 2.1, Rybka 1.0 Beta, and Rybka 2.3.2a all give a penalty for an isolated pawn that depends on whether the file is half-open or closed [as does Faile].
• Fruit 2.1 and Rybka 1.0 Beta both give a bonus to a rook on the 7th rank when the enemy king is on the 8th rank, or there is an enemy pawn on the 7th. [Rybka 2.3.2a gives a bonus when there is a king or pawn on the 7th or 8th]. Similarly with a queen.
• Fruit 2.1, Rybka 1.0 Beta, and Rybka 2.3.2a all penalise a White rook on a1/a2/b1 when the king is on b1/c1 (and symmetrically).
• Fruit 2.1 and Rybka 1.0 Beta both reduce the score by a factor of 2 in strict opposite bishop endings when the pawn imbalance is 2 or less. Rybka 2.3.2a does the same, except that (due to bit-packing) the score is also halved when the pawn imbalance is 6 or more.
• Mobility in each is based on number of squares attacked (pseudolegal moves) and therein linearly weighted (though Fruit does subtract off an "average" amount), and is done for all QRBN pieces (knights disappear in R232a).

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

[BB+]

I am not questioning the case. I am just saying you need to be sure the source provided matches the exe that plays.

This, indeed, was a major concern in the afore-cited Rybka/Junior negotations (coming from Rajlich's $100,000 Challenge). And let's us not forget that for a long time the Rybka forum was claiming that the R232a version investigated by the ICGA was "not the same" as the 2007 WCCC version (and thus even invalidated the investigation in toto, if one were to listen to the extremal voices), as VR had prepared a special version with a hard-coded tablebase path for Cimotti to use.

[BB+]

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), I really don't think I would be a good choice. 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).

I you are actually talking about creating such a "third party" to examine the case (all aspects) then I argue strongly about giving it to one person. There is no transparency to the decision, the WHY is essentially unknown, so why would anyone disagreeing accept it? Such a third party would need to be a group one, with ALL discussions and decision process OPEN. Interested parties should submit word-limited papers to it (possibly no more than 400 words) and the group discuss them. It is unlikely there is any need for "more evidence", evidence abounds already, its interpretation that is needed. The group will be biased, but is should be balanced in bias with known neutrals holding the balance. Noisy people who talk too much should NOT be on it, they are limited to the 400 word paper and answering any questions that arise, but they don't have right of posting. Group, say of five or so, should be sourced from the forums, people who have intelligently expressed comments in the past. I can think of a few right now, including some neutrals. Group forum open to read by anyone.

Complicated......... And, no consequences for the ICGA?

It would have nothing to do with the ICGA, it would be a forums created process. ... ICGA can choose whether to agree with the idea and go along with its conclusions (if any) or not, doesn't really matter what they do. I think you place too much emphasis on what ONE lone person (Levy) who really is out of comp chess for many many years, thinks, or wants. So what to what Levy thinks? Does he know, any better than any random forum reader? No.

No consequences for anyone, as far as I can tell... Rather, just another forum grouping, where Rybka can be discussed to death. How is it different from the current situation, other than it gets some pompous name?