Previous World Champion Engine Authors Speak Out...

[bob]

NO it isn't "a fact". There are parts of my eval that are not "bitboard-centric". Low-level stuff is, but not all. Ditto for move generation. One can hide much with macros.

You can hide everything with macros if you create enough of them, but that's "in theory". Let's stick to the actual relevant case.

1) Fruit uses board->square[from] a lot, it doesn't translate to bitboard. Fruit is also full of magic numbers (offsets) that doesn't translate. It's a totally different approach to doing move generation with bitboards where you work with bitwise operators and mask out bits.

Not so fast. Is Crafty bitboard? Yet it _still_ has board[64]. So Fruits eval could be made to work in the crafty framework with not a lot of effort, mainly just dealing with renumbered squares since my board is only 64 elements. It would be a decidedly "unbitboard" approach, but it would work just fine since tree->board[from] would work. Or you could use Board(from) which is a macro I use to make the code easier to read... Move generation shouldn't be done using that array, but it could.

2) Evaluation has the same issues. Lots of board->square[to], piece lists and pattern matching that looks completely different in bitboards.

"Should" look completely different. See above. You can use Board(from) in Crafty anywhere you want to get the piece on square "from". No bitboard accesses and MSB/LSB operations required. Not how bitboards are intended to work, but they _can_ be used like that...

"Could", "might", "is possible". I don't know what you're seeing but I don't see a whole lot of Board(from) going on.

Just read what I wrote. I don't use Board(x) in the evaluation. But I could, because it is there and it is incrementally updated as the moves are made. So one could quite easily graft the fruit evaluation onto Crafty without having to rewrite all the code. Without having to rewrite any of the code, except to change the square numbers to convert from fruit numbering to Crafty numbering...

3) You've stated yourself for years that coding bitboards requires a different way of thinking. Why the sudden change of mind?

Simple. The difference between "should" and "could". It is clearly possible to stuff the fruit eval right into Crafty. Deal with the re-numbered squares since the two programs use two different array sizes for the mailbox board, and you are ready to go. It would not be as fast, it would not be a "clean bitboard" program. But you can't say "impossible"... That was my point.

"Could, would, should"... I've never said "impossible". I said _unlikely_, as it would be faster in more ways than one to write it from scratch with bitboards.

That is simply nonsense. How can you _possibly_ write an eval from scratch and do it it less than a day or two? And that is all it would take to stuff the fruit eval into Crafty. I renumbered the bits in Crafty, and got rid of the black/white duplication, and it took a couple of months of rewriting.

4) This is not about Crafty. I could state that you cannot easily convert Frenzee to mailbox by changing a few macros, but this is not about Frenzee either.

Are you following the discussion? We now know that the pre-fruit version of Rybka copied a lot of crafty source. So now the issue becomes taking the fruit eval, plugging it into Crafty. Slowly getting rid of the array references and use bitboard operations. But at each step along the way, you have a working version to compare the new bitboard version to, to simplify testing/debugging.

So this is about Crafty _and_ Fruit...

Ah no really
But you're saying that Crafty was actually the starting point, so Rybka was derived from Crafty and not Fruit, only parts of Fruit was converted? Basicly you're now telling me I was right all along!!

I am saying that the pre-fruit versions of Rybka were Crafty. The post-fruit versions are _completely_ different from Crafty with respect to overall structure, search, eval, etc. So we have two completely separate cases of "copy and claim".

I _knew_ it wouldn't make any sense to convert Fruit into bitboards, it would have to come from somewhere else or be written from scratch.

I had little trouble converting Cray Blitz to C and to bitboards, at the same time. Lots of code remained unchanged, until I hit move generation which was quite a bit different at the low-level end. The eval was a direct port, but using bitboard approaches to implement the same features found in the non-bitboard CB code.

And then we get to critical things like search, move ordering, pruning, reductions, extensions. He could have copied significant parts.

Anyone could. You'd expect hash move, winning captures, killers and so forth. It's all pretty standard stuff as is nullmove and LMR. You'd need to see something very unsual being used, something identifiable as comming from Fruit. And again ideas can be copied so it would have to be something rather copy-paste like.

Which is exactly what we have been reporting for a couple of years now? Exact matches. And now some examples with oddball bugs that make no sense, yet which appear in both programs? One has to copy these kinds of bugs, or else believe in miracles to think two different programmers compare the return value of a function to a constant that the function has not produced in 10+ years. In Crafty, that code was left in quite by accident. How did it get into _another_ program? Comparing to the exact same constant??? Coincidence??

Right I agree with you there. Identical and very obscure bugs are a pretty tell tail sign that something is not as it should be.

And you are overlooking the issue that we now know that he copied parts of Crafty, which _is_ a bitboard program. Suddenly the changes to Fruit's eval don't appear to be so difficult since all the support code may well have been copied (we are quantifying this as I write.)

So let me get up to speed, the current theory is the following:
Rybka came from a 10 year old buggy version of Crafty, then a Fruit eval was easily plugged into it by using macros. Later all previous references were removed meanwhile maintaining a fully functioning engine. Crafty was the starting base but today Rybka is nothing like Crafty but very Fruitish everywhere as the engine has morphed into Fruit.
Sure very logical, exactly how I would have done it....

Perhaps you were actually willing to write your own code, rather than copy?

First, the structure of Strelka is _nothing_ like the structure of Crafty. Simple to evaluate if you want to lets take procedure by procedure starting at Iterate(). Wait, Strelka doesn't even have an Iterate() function...

Strelka looks fruity. Rybka looks fruity. The pre-fruity version of rybka looks like Crafty. You can ignore the evidence if you want, but none of your comments addresses the specific issues being exposed daily.

So the bitboard structures of Rybka is more like the list structures of Fruit than the bitboard structures of Crafty? I'm having some trouble following the logic here...

Apparently. It would be very easy to take the fruit search and replace Crafty's. No significant bitboard code there. But there is a lot of support code needed to use bitboards. move input/output. Move generation. SEE. Debugging code to display bitboards in a readable form. Initialization of the rotated stuff that Vas claimed to have used until switching to Magic.

If I wanted a bitboard fruit, I would start with a bitboard program that worked and was strong. Crafty certainly fit that. I would then excise the "personality" of Fruit, which would be the eval and search, and transplant that into Crafty, rewriting as I went. Leaving a lot of Crafty intact. A lot of fruit intact. And changing the code at the points where the two distinct approaches are juxtaposed, necessarily. You end up with a lot of Crafty, a lot of Fruit, and some original code. But not a lot of original code.

I'm not the "thought police". But I don't do this sort of obfuscation... And I have not seen an open source program that does.

Why would an open-source engine want to do obfuscation? That would make no sense. However many closed source coders whats to keep their secrets and obfuscation is certain a tool to do that. I'm actually surprised not more people are doing it. Why show any output that could reveal how your engine operates?

You could do it to hide details. Or you could do it to hide origin. Either is equally probable.

[bob]

NO it isn't "a fact". There are parts of my eval that are not "bitboard-centric". Low-level stuff is, but not all. Ditto for move generation. One can hide much with macros.

You can hide everything with macros if you create enough of them, but that's "in theory". Let's stick to the actual relevant case.

1) Fruit uses board->square[from] a lot, it doesn't translate to bitboard. Fruit is also full of magic numbers (offsets) that doesn't translate. It's a totally different approach to doing move generation with bitboards where you work with bitwise operators and mask out bits.

Not so fast. Is Crafty bitboard? Yet it _still_ has board[64]. So Fruits eval could be made to work in the crafty framework with not a lot of effort, mainly just dealing with renumbered squares since my board is only 64 elements. It would be a decidedly "unbitboard" approach, but it would work just fine since tree->board[from] would work. Or you could use Board(from) which is a macro I use to make the code easier to read... Move generation shouldn't be done using that array, but it could.

2) Evaluation has the same issues. Lots of board->square[to], piece lists and pattern matching that looks completely different in bitboards.

"Should" look completely different. See above. You can use Board(from) in Crafty anywhere you want to get the piece on square "from". No bitboard accesses and MSB/LSB operations required. Not how bitboards are intended to work, but they _can_ be used like that...

"Could", "might", "is possible". I don't know what you're seeing but I don't see a whole lot of Board(from) going on.

3) You've stated yourself for years that coding bitboards requires a different way of thinking. Why the sudden change of mind?

Simple. The difference between "should" and "could". It is clearly possible to stuff the fruit eval right into Crafty. Deal with the re-numbered squares since the two programs use two different array sizes for the mailbox board, and you are ready to go. It would not be as fast, it would not be a "clean bitboard" program. But you can't say "impossible"... That was my point.

"Could, would, should"... I've never said "impossible". I said _unlikely_, as it would be faster in more ways than one to write it from scratch with bitboards.

Vasik once told he flipped the coin whether he used bitboards or mailbox:
http://www.stmintz.com/ccc/index.php?id=466930

... to tell the truth, I don't think board representation is all that important. I flipped a coin my first few weeks of computer chess programming, and it said bitboards.

There are enough semantical equivalent pattern in eval which are 1:1 convertable.

Code: Select all

if ( board[f2] == WHITE_PAWN && board[g3] == WHITE_PAWN && board[h2] == WHITE_PAWN ) ...

versus

Code: Select all

if ( (white_pawn_bb & bits_f2_g3_h2) == bits_f2_g3_h2) ...

If an evaluation of a program heavily relies on semantic equivalent and easy convertable pattern, the board representation really don't cares that much ...

Gerd

And in the case of Crafty, one could do _either_ in the eval since I have the 64 byte mailbox array to make it fast to find out what piece is on a square, rather than having to search thru the bitboards to see what is there.

[bob]

In programming, especially a chess program, adopting significantly large and critical blocks of very specific symbiotic logic and factored weights verbatim is only permissible in an acknowledged code fork. It certainly couldn't pass the smell test as an original work. And the distance between subsequent versions to the plagiarized starting point will hardly matter (to most people) if a programmer is shown to be so dishonest.

Ordinarily yes. What makes the Rybka situation special is that Vas couldn't have adopted "significantly large and critical blocks of very specific symbiotic logic and factored weights verbatim" as Rybka is bitboard and Fruit is mailbox. At least for the evaluation and move generation code it would have to be coded completely different - that is a fact. We also know that Rybka has new important material terms in the evaluation and the search seems original as well.
What they need to prove then, is either that some other parts of the engine contains large parts of copied code (for instance the hashing or protocol) or that large parts of the bitboard code is functionally equivalent to the mailbox code. The latter is a bit problematic however, as most engines are known to contain certain large parts of functionally equivalent codes, like for instance the SEE, Qsearch, Nullmove and so forth. No one would claim Fruit was a derivative of Crafty just because it had sections of nullmove code that was functionally equivalent to Crafty for instance.

What annoys me most about this whole issue is that we do not have objective means and rules to specify what is legal to copy and what is not. It's always a judgement call in every single case. This makes the whole process too ad hoc and un-scientific IMHO.
The process should be reversed, first we need to establish what is legal and what is not, then we need to decide how to punish the rule breakers and only then does it make sense to begin considering the individual engines. Otherwise we are having a trial and jury with no accepted laws to judge by.

Amen to that! Above we actually have a man with a brain that is not afraid to speak out and tell the truth.

Not quite. If someone wants to add the fruit eval to Crafty, it would not take but a day or two.

In this case it may be interesting if people do it and test to see if fruit's evaluation make Crafty worse or better in games(and the same for stockfish's evaluation that I guess it is not harder to add).

I do not believe it would make it stronger. At one point we looked at the fruit eval carefully and found nothing that we didn't think we were doing better. The main component in Fruit's eval is mobility and ours is certainly better today, not being just a simple count of reachable squares, but having weighted values for each square.

One could certainly try it to see...

[bob]

In this case it may be interesting if people do it and test to see if fruit's evaluation make Crafty worse or better in games(and the same for stockfish's evaluation that I guess it is not harder to add).

This seems rather uninteresting unless the "cobbler" publishes the code... and that will require explicit permission from all engine authors involved, since Crafty's license and the GPL are incompatible.

Not incompatible for that purpose. Both licenses require that the source changes be released, which would work just fine. The only sticking point is that the modified Crafty might have to be released under the GPL, which could be arranged. And if the program is never distributed, no problems of any kind would be encountered.

[UncombedCoconut]

In this case it may be interesting if people do it and test to see if fruit's evaluation make Crafty worse or better in games(and the same for stockfish's evaluation that I guess it is not harder to add).

This seems rather uninteresting unless the "cobbler" publishes the code... and that will require explicit permission from all engine authors involved, since Crafty's license and the GPL are incompatible.

Not incompatible for that purpose. Both licenses require that the source changes be released, which would work just fine. The only sticking point is that the modified Crafty might have to be released under the GPL, which could be arranged. And if the program is never distributed, no problems of any kind would be encountered.

The problem I saw is that it would violate the GPL to impose restrictions on entering the program in tournaments. But I misspoke; it's enough if all copyright holders of either program allow release under the other program's license... and today's Crafty would beat up a Crafty 19.x / Fruit 2.1 hybrid.

[SuneF]

Vasik once told he flipped the coin whether he used bitboards or mailbox:
http://www.stmintz.com/ccc/index.php?id=466930

... to tell the truth, I don't think board representation is all that important. I flipped a coin my first few weeks of computer chess programming, and it said bitboards.

There are enough semantical equivalent pattern in eval which are 1:1 convertable.

Code: Select all

if ( board[f2] == WHITE_PAWN && board[g3] == WHITE_PAWN && board[h2] == WHITE_PAWN ) ...

versus

Code: Select all

if ( (white_pawn_bb & bits_f2_g3_h2) == bits_f2_g3_h2) ...

If an evaluation of a program heavily relies on semantic equivalent and easy convertable pattern, the board representation really don't cares that much ...

Gerd

For any given small piece of code the translation could be done, but to convert an entire program line by line seems like too large a refactoring to be realisticly possible in a single step. If your rip out the bitboards from the Board struct in Crafty you will probably get 1000 errors and a total refactoring nightmare.
I'd want to break it down and unit test individual classes and methods step by step from the ground up. First I'd want to get the move generator running and debugged - but it wouldn't even compile at that stage due to the evaluation, search and what not errors. So basicly you'd have to comment out the rest of the program while you debugged the move generator.
I think there comes a point where it is faster to start over than to refactor and changing the position representation clearly crosses that line for me.
Most of us have zero abstraction due to performance reasons, the couplings are so tight and lowlevel, the representation is not a protected variation. Implementing an interface in the Board class and abstracting from the details of the representation would make it almost trivial to change the representation, but it would come at a performance cost.

[Gerd Isenberg]

Vasik once told he flipped the coin whether he used bitboards or mailbox:
http://www.stmintz.com/ccc/index.php?id=466930

... to tell the truth, I don't think board representation is all that important. I flipped a coin my first few weeks of computer chess programming, and it said bitboards.

There are enough semantical equivalent pattern in eval which are 1:1 convertable.

Code: Select all

if ( board[f2] == WHITE_PAWN && board[g3] == WHITE_PAWN && board[h2] == WHITE_PAWN ) ...

versus

Code: Select all

if ( (white_pawn_bb & bits_f2_g3_h2) == bits_f2_g3_h2) ...

If an evaluation of a program heavily relies on semantic equivalent and easy convertable pattern, the board representation really don't cares that much ...

Gerd

For any given small piece of code the translation could be done, but to convert an entire program line by line seems like too large a refactoring to be realisticly possible in a single step. If your rip out the bitboards from the Board struct in Crafty you will probably get 1000 errors and a total refactoring nightmare.
I'd want to break it down and unit test individual classes and methods step by step from the ground up. First I'd want to get the move generator running and debugged - but it wouldn't even compile at that stage due to the evaluation, search and what not errors. So basicly you'd have to comment out the rest of the program while you debugged the move generator.
I think there comes a point where it is faster to start over than to refactor and changing the position representation clearly crosses that line for me.
Most of us have zero abstraction due to performance reasons, the couplings are so tight and lowlevel, the representation is not a protected variation. Implementing an interface in the Board class and abstracting from the details of the representation would make it almost trivial to change the representation, but it would come at a performance cost.

My understanding of a "real" bitboard program, is that it is not trivially convertible to mailbox as well. But there are those let say "pseudo" bitboard programs where it is possible by design, may be after the first step from "translation" from mailbox.

You don't need virtual function call overhead to abstract the board representation from search and most eval stuff, inline functions or macros could do the job. See for instance Fritz Reul's thesis and the design of Loop and List.

[Tom Barrister]

I've been following the latest few pages here, and while the technical part is beyond me, the gist of what's being discovered isn't.

From what I'm reading, the gist is that the latest beliefs are:

The very early versions of Rybka or pre-Rybka were taken near-verbatim from Crafty and then changed or added to in some way.

At some point, some/many things from Fruit were plugged in and made compatible with what was there already (i.e. Crafty).

Then it was rewritten to make the transition from mailbox to bitboard(s).

So if the assumptions of Mr. Hyatt and company are correct, Mr. Rajlich started his chess programming career by plagiarizing/stealing-from (insert your own word(s) if neither of those work for you) Crafty. After making some alterations, he then improved this engine by plagiarizing/stealing-from Fruit.

And now I get the impression that some of the Rajlich supporters think that Mr. Rajlich has been exonerated because it's been proven that Rybka 1.0 beta wasn't entirely based upon Fruit.

Baloney.

If Mr. Rajlich has done this not once, but twice, it would be ludicrous to believe that he hasn't been doing it all along, meaning since then as well.

In other words, it's not a stretch to believe that Rybka 2 stole ideas from some engines, Rybka 3 stole ideas from some more engines, or that Rybka 4 stole even more ideas from other engines.

It's quite possible that the mighty Rybka could be a mosaic of the best features of the various engines out there. It could be any or all of various things taken from:

1) The open source engines.

2) Closed source engines to which he somehow got the code, via others.

3) Closed source engines that were decompiled/reverse-engineered (or whatever the correct term is).

4) Ideas gleaned from reading various discussions or from talks with others.

So Mr. Rajlich's abilities as a programmer may be as a decompiler and whatever tech-speak term describes somebody who can take the ideas of others, and/or whatever works in other programs, and patch them into his engine.

For all we know, Rybka may be an aggregation of Crafty, Fruit/Toga, Zappa/(Paderborn), Shredder, Hiarcs, Fritz, Junior, Glarung/Stockfish, Spike, Pro-Deo/Rebel, Loop, Chess-Tiger, Ruffian, Jonny, Spike, Bright, Sjeng, etc.

Rybka might not have original idea one in it, save for what's needed to make the thing work.

Mr. Rajlich is a strong chess player, That would certainly help him figure out what worked best. A lot of testing of various bits and pieces would also help weed out the bad parts and validate the good.

Of course, the Rajlich supporters will rise up and say "you can't prove (whatever)!". I don't need to. The cliche "Once a thief, always a thief" comes immediately to mind. As I said earlier (and long before the allegations of (pre) Rybka containing Crafty came up), it would surprise me if Rybka didn't contain bits and pieces of several engines. Somebody who will wholesale-copy something over and claim it to be original won't usually have any scruples about doing the same in the future.

Nor would it matter if Mr. Rajlich never cheated again after version 1.0 beta. Nor would it matter if Rybka 2, 3, and/or 4 were completely rewritten from scratch, a prospect which to me seems about as likely as Osama bin Laden being invited to the White House for dinner. One violation is too many, and the brazen way in which it's been perpetuated and defended shows little or no remorse for the actions, nor any intention to admit such actions or correct them in the future.

[Sean Evans]

I took a look at the Rybka forum to see if this topic was allowed to be posted and it was there. I was fascinated by the fan-boys trying to defend Rybka as an original program

http://rybkaforum.net/cgi-bin/rybkaforu ... ?tid=21059

Cordially,

Sean

[Sean Evans]

I've been following the latest few pages here, and while the technical part is beyond me, the gist of what's being discovered isn't.

From what I'm reading, the gist is that the latest beliefs are:

The very early versions of Rybka or pre-Rybka were taken near-verbatim from Crafty and then changed or added to in some way.

At some point, some/many things from Fruit were plugged in and made compatible with what was there already (i.e. Crafty).

Then it was rewritten to make the transition from mailbox to bitboard(s).

So if the assumptions of Mr. Hyatt and company are correct, Mr. Rajlich started his chess programming career by plagiarizing/stealing-from (insert your own word(s) if neither of those work for you) Crafty. After making some alterations, he then improved this engine by plagiarizing/stealing-from Fruit.

And now I get the impression that some of the Rajlich supporters think that Mr. Rajlich has been exonerated because it's been proven that Rybka 1.0 beta wasn't entirely based upon Fruit.

Baloney.

If Mr. Rajlich has done this not once, but twice, it would be ludicrous to believe that he hasn't been doing it all along, meaning since then as well.

In other words, it's not a stretch to believe that Rybka 2 stole ideas from some engines, Rybka 3 stole ideas from some more engines, or that Rybka 4 stole even more ideas from other engines.

It's quite possible that the mighty Rybka could be a mosaic of the best features of the various engines out there. It could be any or all of various things taken from:

1) The open source engines.

2) Closed source engines to which he somehow got the code, via others.

3) Closed source engines that were decompiled/reverse-engineered (or whatever the correct term is).

4) Ideas gleaned from reading various discussions or from talks with others.

So Mr. Rajlich's abilities as a programmer may be as a decompiler and whatever tech-speak term describes somebody who can take the ideas of others, and/or whatever works in other programs, and patch them into his engine.

For all we know, Rybka may be an aggregation of Crafty, Fruit/Toga, Zappa/(Paderborn), Shredder, Hiarcs, Fritz, Junior, Glarung/Stockfish, Spike, Pro-Deo/Rebel, Loop, Chess-Tiger, Ruffian, Jonny, Spike, Bright, Sjeng, etc.

Rybka might not have original idea one in it, save for what's needed to make the thing work.

Mr. Rajlich is a strong chess player, That would certainly help him figure out what worked best. A lot of testing of various bits and pieces would also help weed out the bad parts and validate the good.

Of course, the Rajlich supporters will rise up and say "you can't prove (whatever)!". I don't need to. The cliche "Once a thief, always a thief" comes immediately to mind. As I said earlier (and long before the allegations of (pre) Rybka containing Crafty came up), it would surprise me if Rybka didn't contain bits and pieces of several engines. Somebody who will wholesale-copy something over and claim it to be original won't usually have any scruples about doing the same in the future.

Nor would it matter if Mr. Rajlich never cheated again after version 1.0 beta. Nor would it matter if Rybka 2, 3, and/or 4 were completely rewritten from scratch, a prospect which to me seems about as likely as Osama bin Laden being invited to the White House for dinner. One violation is too many, and the brazen way in which it's been perpetuated and defended shows little or no remorse for the actions, nor any intention to admit such actions or correct them in the future.

Well said Tom, I think you have summarized my beliefs in one post

Just out of curiosity is it relatively easy to stop programmers from breaking into a chess programs software? I believe MS Windows has such protection.

Cordially,

Sean