mjlef points out that I conflated RobboLito and IPPOLIT null move constraints (for a side to do null move, RobboLito demands a piece, while IPPOLIT does not. The relevant text now reads:
Code: Select all
Both turn off null move for a side when it has only pawns left, IPPOLIT via a flag in a material table (in RobboLito, a minor piece is needed for null move), and Rybka via a direct computation (via {\tt or} of BNRQ bitboards -- IPPOLIT has a similar ``computation'' in a pruning condition for low-depth search via {\tt xor} of the occupied with the PK bitboards).
I do not find the "not a king move" constraint particularly interesting, it is just common sense. It is meaningless to call SEE on king moves, especially if you check for legality in the movegen. If a king move is legal, then its SEE will be always good.
Indeed you are right, and most annoyingly, I'm pretty sure I thought of your explanation when I first noticed this, but evidently it didn't stick well enough in my mind. Common sense is rather uncommon.
As an aside, both Rybka and IPP_ENG.c pre-eliminate king moves to squares the opponent attacks, but both do so only in generation of ordinary moves, and not in capture moves. The same looks true for the latest IvanHoe:
Code: Select all
sq = BSF (BitboardMyK); // capture gen
T = AttK[sq] & mask;
Code: Select all
sq = BSF (BitboardMyK); // ordinary gen
T = AttK[sq] & empty & (~OppAttacked);
BTW, how many months of work did it take? Just curious........
As with Dann Corbit (and probably others --- DC at least openly says he did), from the first day I obtained R3 I was fooling around with it. And I had looked a bit at previous versions, and for that matter, having the Strelka source code at hand can be of some use. Figuring out the node-count obfuscation didn't take too long, and I did some more dabbling after that. There was an actual repeatable crash (found by Nelson Hernandez
http://rybkaforum.net/cgi-bin/rybkaforu ... pid=122549) that was reported a few months after the release, and I was able to track that down as a 32-bit/64-bit problem (the direct cause at least -- things had gone askew before this). I think I was away from the Rybka forum from like July to November (in 2009), but when I returned I started some RE in more earnest. Then I checked out for a month or so again, and starting posting some semi-detailed comparisons when I returned (it was at this time that I corresponded more with Larry Kaufman about the eval --- I don't think he knows me other than as BB). Ironically, it was M ANSARI who kept on saying (essentially) that when I dug deeper into it I would find more evidence of cloning. Along with my difficulties with the moderation at the Rybka forum, I then decided that an academic-style report was a better bet than piecemeal snippets, and when I spoke with Zach in March, he was also interested in the idea. It then took me 2 more months to complete the report.
I have a proposal that might help. If you are able to tell me how ProDeo detects a passed pawn that would be proof enough for me you are able to do a RE job, thus your skills. After all your document is all about RE.
I will glance at ProDeo, and see if this is a reasonable proposal (that is, whether I think I would have to understand too much of the totality of ProDeo to zero-in on this one aspect).
In an ideal world I would agree with you. The paper is a bomb under the credibility of Vas, a programmer who ruled the computer chess world for years.
I disagree with this. My impression is that VR simply had some all-too-human blinders, and didn't necessarily make fine distinctions with "cloning" and "derivative" and "code" when he spoke about it. The crazy IPPOLIT style of release can't be said to have helped matters (and it has been speculated that their zaniness was intentionally provocative in this manner).
