Ed, what you describe here is a generalised method failure which has been pointed out several times in the past (by me mostly) but ignored or casually dismissed by the attack side.

The attack side is aware of the abstraction-filtration-comparison procedure for comparison of two code sections. They are aware at the filtration stage of removing from consideration (filtering) PD code, code that has only one way of being written etc, for it obviously not fair to include such code before making comparisons. So far so good.

But, when they moved up a level from code comparison (because it didn't work for them to prove copying) to semantic comparison, they needed also to uprate their "filtration tests" at the level. They did not do a filtration stage at all. Hence they left in, and claimed comparison rights on code it was not FAIR to compare.

What you are basically saying is this: it is not fair to COMPARE code between two programs, semantically or otherwise, when that code (or semantics) is in general use elsewhere and by others.

Or, in particular, when MG/EC interpolation is in use by Phalanx, Fruit, Rybka, Crafty etc. then it is not FAIR to pick out the usage by Fruit and Rybka and claim COPYING. For starters, they could both have copied it from Phalanx and not each other. Or independently come up with the idea. Or read about somewhere else and implemented it. Are there indeed more than one way to implement the idea? Possibly not, or just one obvious way.

In general, the needed a FILTRATION test at SE stage, which asked, is this code is general or widespread use? And, which asked, once one has the idea, is there actually more than one obvious way to implement it. If either one of those questions flags up, then the semantic or code section has to be FILTERED out before any comparison. This is what they failed to do. Systemic error invaliding ALL SE comparisons.

I do not see the opening/endgame evaluation being a strong piece of evidence against Rybka.  The panel did indeed found it in one program before Fruit(Phalanx--though there may be others).  It is not one of the scored evaluation criteria in the document below.  It is indeed a unique scheme (at least among open source programs before 2005), but no score was placed on it in the analysis.

In fact, in the backward pawn code, the panel found a difference between Fruit 2.1 and Rybka.  If you read this report:

http://icga.wikispaces.com/file/view/EVAL_COMP.pdf

you will find:

"Fruit 2.1 checks first that no adjacent-file pawn is behind or equal to the rank
of this one, and then checks to see if by advancing in one move this pawn can
meet up with a friendly one, ignoring this latter condition when an opponent's
pawn attacks the advance square. A penalty is then given based upon whether
the le is half-open or not. Rybka 1.0 Beta and Rybka 2.3.2a do the same
first check, and then see if by advancing one or two squares (not necessarily in
one move) whether a pawn can meet a friendly one, again without an enemy
pawn intervening by an attack (a minor difference is that Fruit 2.1 checks that
a friendly pawn, necessarily doubled, does not block the \backward" pawn's
advance). A penalty is then given based upon whether the file is half-open or
not."

And you can see further in the report that the overlap between Fruit and Rybka for backward pawn scoring is scored as merely 0.7, showing a strong but not nearly perfect overlap.  The backward pawn scoring was clearly marked as being not a perfect match, and fully acknowledged in the report.

Have you read the report?  It really does give credit for the differences.  But even with the difference the evaluation overlap is very high. 74% in fact.

I suggest you go through the report, and cite any inaccuracies.  IN fact this is encouraged and why we have opened up all the documents for review.

No, that is NOT correct.

The MG/EG interpolation is an idea.  What is important is the WAY the tests are done.  Back up one step so that the two EG/MG scores combine into one line, since SEVERAL programs use this approach.  Now what do you see?  You do NOT focus on 4-5 lines of code, you focus on a block of code that does something useful.  For example, the trapped bishop code you posted.  Do Crafty and Fruit do the SAME thing in terms of what they check?  And we can even factor out the actual "bonuses" since anyone can change a single constant, agreed? 

So, Crafty checks a bishop on a7 with a pawn on b6, or a bishop on b8 with a pawn on c7, duplicated for the other corner on the same side of the board.  And then duplicated for the other side of the board at a2/h2.  For any condition that is true, I add a penalty.

Fruit checks for a bishop on a7 and a pawn on b6, or a bishop on b8 with a pawn on c7 (ditto for other 3 corners.)  If any one is true, fruit adds a penalty.  Then fruit checks for a bishop at a6, and a pawn at b5, the other 3 corners as well, and if any condition is true, it adds 1/2 the penalty it added for the a7/b8 case.

Now does that REALLY appear to be semantically equivalent?  If you use the SAME penalty in both programs, you won't get the same score for all positions since Crafty doesn't check the a3/a6/h3/h6 squares at all, nor does it add in any 1/2 penalty for those.   Why is that so difficult to understand.  You want to take 3-4 lines of code and say "Hey, a match." (which might well show that Fabien looked at Crafty since Crafty did things Fabien did, at least a couple of years prior to fruit existing.  We took individual pieces and features and compared them.  Not just cherry-picking 3-4 lines, but taking the ENTIRE block of code from each.  Often they were the same.  Occasionally there was something different.  The more such blocks that match, the more likely code was copied and translated to bitboard (or just outright copied in some places that did not reference board structures at all.

As I said, your concept of "semantic equivalence" is flawed.  One doesn't apply it to a line here and a line there.  One applies it to a complete function, or a complete block of code, and too many matches are revealing.  Also, your SE is flawed because that "test instruction" is the wrong place to start.  One has to back up to see what is in al that is being tested.  If one is testing for a passed pawn, and one is testing for an outpost knight, then of course they are not "semantically equivalent".  SE analysis has to work within context, not just a half-dozen asm instructions by themselves with the "input" totally missing...

Your "concept" here is wrong.