Where is the evidence to be found?

[chrisw]

I read many times now that Rybka is a bitboard program and Fruit not, presumably Fruit uses 0x88

For non-chess-programmers this means that the internal representation of the chess board and pieces in program memory (the data structure) could not be more different.

To sustain the postion that Rybka is a derivative of Fruit the accusers are going to have to find unexplainable code similarities between the two engines. We're talking of chess engines, so we're not interested in the UCI part of the program, solely the engine part, where the AI exists.

Now, a chess engine can conceptually be divided up into various parts.

Generate moves
Move and unmove
Evaluate a position
Search

Genmove, move and unmove all have to obey the rules of chess, and they all operate on and are dependent on the data structure of the program. Since Fruit and Rybka have wildly different data structures, the accusers are not going to find any code similarities in any of those component parts. So they won't even bother looking there.

Evaluate has much scope for programmer creativity, but again, the routine spends much of its time interrogating the data structure, and again, Fruit and Rybka with wildly different data structures are unlikely to be providing evidence of similarity in Evaluate either.

If Rybka came from Fruit, and uses bitboards when Fruit doesn't, then a developer from one to the other would need to completely rewrite move, unmove, genmove and evaluate. Actually these parts comprise the bulk of any chess program.

That leaves Search. Search is broadly independent of data structure and it could be one place where similarities could be found, if there are any. It's therefore no surprise that Zach's disassembly chunk is of part of Search. The question is begged - why, assuming its the case, since the main bulk of Fruit would have to be rewritten anyway, why not rewrite Search also? It's relatively not a difficult task in comparison. We also know Rybka is pretty damn strong - that won't have been done by a quick copy of somebody else's Search routine, but by some serious and special development.

Now the problem of using Search to prove similarities is that Search across a wide range of engines uses known similar techniques. It does things in a certain order that's been established as most efficient. Move ordering for example is a case where most programmers do the same thing (discussed elsewhere). If similarities are found they are likely to be down to use of ideas rather than code copying.

Personally, I think the accusers are flogging a dead horse. They have no case.

[Guetti]

What is the problem with evaluate?
Most bitboard engines have also an normal board array. And piece lists could be generated in the eval from bitboards. With these two things, one could probably insert the fruit evaluation almost as it is. (I'm not an expert in fruits data structures, so correct me if I'm wrong).

This doesn't mean that I believe Vas actually did that. I think he had his own ideas for the eval. Just to say the possibility can not be ruled out in advance.
I leave that to the experts to analyse.

[chrisw]

What is the problem with evaluate?
Most bitboard engines have also an normal board array. And piece lists could be generated in the eval from bitboards. With these two things, one could probably insert the fruit evaluation almost as it is. (I'm not an expert in fruits data structures, so correct me if I'm wrong).

This doesn't mean that I believe Vas actually did that. I think he had his own ideas for the eval. Just to say the possibility can not be ruled out in advance.
I leave that to the experts to analyse.

Well, maybe evaluate would be worth evaluating, although, I'ld have thought that if the modus was Fruit -> Rybka, converting to bitboards, then intention would be convert entire program. It makes not much sense (program speedwise) to be 0x88-ing and bitboard-ing.

[bob]

What is the problem with evaluate?
Most bitboard engines have also an normal board array. And piece lists could be generated in the eval from bitboards. With these two things, one could probably insert the fruit evaluation almost as it is. (I'm not an expert in fruits data structures, so correct me if I'm wrong).

This doesn't mean that I believe Vas actually did that. I think he had his own ideas for the eval. Just to say the possibility can not be ruled out in advance.
I leave that to the experts to analyse.

Well, maybe evaluate would be worth evaluating, although, I'ld have thought that if the modus was Fruit -> Rybka, converting to bitboards, then intention would be convert entire program. It makes not much sense (program speedwise) to be 0x88-ing and bitboard-ing.

"sense" does not matter. I know of multiple programs that are hybrids. Vincent said he uses a mailbox board, but uses bitboard stuff for pawn evaluations. Cray Blitz was a mailbox program that used bitboards for things like attack detection (in check, etc). And this is actually a key point. There are so many alternative ways to write a chess engine, the chances of two sharing identical blocks of code is vanishingly small. It is possible (and even likely) that certain data structures might be duplicated, because the literature is full of such explicit examples (bitboards in slate/atkin paper in Chess Skill book). But even then, there are variations. They didn't mention (nor use) the two extra bitboards I have been using since I started (bishops/queens and rooks/queens). So there is some room for differences even in major data structures like the chess board. And there is some room for similarity with certain module names and variable names. "score" is pretty obvious for a variable name. Ditto for ply, depth, draft, and such. But the names quickly become unique when you talk about other things like evaluation terms and temp variables. And then the code, the code. That is where the differences are expressed.

[henkf]

Why don't you give them some time to produce the results of their research, instead of flaming the results before they are produced?

[Albert Silver]

Why don't you give them some time to produce the results of their research, instead of flaming the results before they are produced?

Well, considering they have started threads, and produced hundreds of posts on the matter, it seems strange to me to be asked to now wait for the results to be produced. What were the claims based on? The number of letters in the name?

Furthermore, the evidence presented will have to show that it is what helps Fruit play as well as it does, and this is also what helps Rybka play as well as it does. Otherwise, the evidence really wouldn't be any better than identical UCI protocols.

Albert

[kranium]

Why don't you give them some time to produce the results of their research, instead of flaming the results before they are produced?

Well, considering they have started threads, and produced hundreds of posts on the matter, it seems strange to me to be asked to now wait for the results to be produced. What were the claims based on? The number of letters in the name?

Furthermore, the evidence presented will have to show that it is what helps Fruit play as well as it does, and this is also what helps Rybka play as well as it does. Otherwise, the evidence really wouldn't be any better than identical UCI protocols.

Albert

i get it...
it's ok to copy code, just not 'important' code...ok i didn't know that.

[henkf]

I don't think it's strange at all. Chris demanded from Zach to present the 'proof' in such a way that it would convince an 'average' ( if not all ) member. This is no simple task. I think for most members ( including myself ) an assembler to random bible texts translation makes as much sense as an assembler to C translation. So probably more needs to be done. I don't even think the request from Chris to Zach was fair, but at least it's strange while the request was coming from him, he's now acting like a child one week before Christmas.

[bob]

Why don't you give them some time to produce the results of their research, instead of flaming the results before they are produced?

Well, considering they have started threads, and produced hundreds of posts on the matter, it seems strange to me to be asked to now wait for the results to be produced. What were the claims based on? The number of letters in the name?

Furthermore, the evidence presented will have to show that it is what helps Fruit play as well as it does, and this is also what helps Rybka play as well as it does. Otherwise, the evidence really wouldn't be any better than identical UCI protocols.

Albert

What _is_ the intent here. To deflect attention elsewhere once more? The evidence does _not_ have to show that is what helps fruit do anything. It only has to show that fruit was copied. Where are you trying to go with this? The goal of the two original investigators here was to simply answer the question "was rybka derived from fruit?" why is it necessary to have a continually shifting target and why do others get to dictate what Zach and Christophe were trying to answer?

Quite simply, copying _any part_ of a GPL program is not permissable. _any part_. Not just "key parts".

[Alexander Schmidt]

We're talking of chess engines, so we're not interested in the UCI part of the program,

It is nearly impossible to compare an open source code with an executeable, so it is a good way to compare the engineoutput in general to see if there is a work based on another engine.

It's not up to you to decide what kind of profes are enough, everyone should draw his own conclusion.

Fabien is not interested, so I am not interested too. I just show the similaries.

Many people are not interested in this issue, they got a monster engine and everything is fine. Of course Rybka is a great piece of work, very different to Fruit in many areas.

The only question is, did Vas take some help at start with his great new ideas in chessprogramming, if so, it was not within the GPL and illegal. And it don't matter if now every single line in Rybka is different to Fruit, or only the UCI I/O was taken from Fruit.

ANd we have two independent analysis, one based on decompiling, one based on the output, that it is at least possible.