OpenChess

Chris Whittington wrote:

hyatt wrote:

Chris Whittington wrote:

Rebel wrote:Allow me some remarks. I deliberately take the Vas=innocent position for the sake of the discussion.

BB+ wrote: Here is a list that I came up with (again I rely partially on ZW) of "suspicious" things in Rybka:
* Re-use of exact same File/Rank/Line arrays in PST values (as opposed to an "idea" where statics would be built up in this way, but with different numbers)

One can only add the word suspicious if one have checked more programs (say 10-15) and found no such similarities. Perhaps things like these are common in many chess programs. Have Bob, Zach, you, checked 10-15 programs for its absence?

* Time management and UCI parsing, particularly the "0.0" appearance

The 0.0 case is indeed suspicious. UCI parsing: perhaps its code is public domain. Fabien took it and so did Vas. Has this option been researched by Zach, Bob and you?

* Copying of the position at the top of the search (Fruit actually copies it back at every iteration), which is pointless as-is in Rybka (it is copied back after the search, again for no reason). Both search 4 ply when a move is forced. [You can also include setjmp under this "Search Start" heading if you like, and I haven't checked whether Rybka actually copies the position, as opposed to Strelka].

Mine does the same, copy the board before the search starts. It doesn't matter if that is pointless, there are many things in mine that are not in use, they are either remains of previous ideas and forgotten to remove or I leave them there on purpose for future ideas.

Mine searched forced moves 3 plies in the early days until I increased it to 5 in order to have a better move to ponder. I don't see the relevance, 4 is an excellent value also and I suspect most programs do it this way.

* Great similarity in evaluation. Here the "ideas" concept comes into play. Specific things could be the 1:2:4 weighting of minor:rook:queen (why not 3:5:9?) and the identical minutiae with the DrawBishopFlag -- to offset the former, Fruit has a linear interpolation across phases, while Rybka's is more complicated.

Using Vas own words: I took many things. I don't see the relevance.

When I was going through the Fruit-eval I wrote down 2 ideas, code for trapped (white) bishop (h6/a6) and the code for freeing ones rook in Kg1<>Rh1 situations. It's perfectly legal to add these ideas to mine, release it without any breach of the GPL. Again, what's the relevance?

* The use of 10, 30, 60, 100 weighting in passed pawns. If this were a one-off, I could believe the recurrence of this numerology was accidental.

Mine has similar values. It's not suspicious at all.

Ed

To add to this .... Bob has always made a meal out of the setjmp instruction in Rybka and Fruit, claiming nobody else does it.

Well, I used the technique in 1980-something in Z80 assembler to jump out of the search, all you need to do then is reset the stack pointer and you're fine, back at the tree root. I changed to a more 'acceptable' method of unwinding back up the tree after staff programmers made a huge fuss about how uncompliant the technique was. But, Oxford Softworks later licensed a small chess program source for porting to various small platforms and I was surprised to see the programmer using setjmp (ie jump out of the search and reset vital pointers), told him to get 'proper(!)' and he refused, claiming it was just fine. This was a highly educated and qualified university guy who wrote masses of complex stuff in a bunch of fields and was highly reliable for producing bug free code, fast.

Absolutely impossible, because setjmp() and longjmp() are _C_ things. I did things remarkably different in Cray Blitz. We used an iterated search so that when time ran out, we just exited the search function instantly. Doesn't work for recursive implementations, which I'd be willing to bet you didn't do in assembly language due to the inherent messiness. This is about how do you get out of a deep recursive stack of calls as quickly as possible. The setjmp()/longjmp() approach is a horrible solution. Global variables are in an unknown state and you have to clean them up and get them back to "sane". What about locks()? state of a file if you are writing a log? Board state assuming, logically, that no one does copy/make due to performance issues. Just because one person says "it is OK" certainly doesn't mean it is. I've seen lots of university CS faculty that write horrible code, and some that can't write code at all.

Why you think it impossible? The functional equivalent for Z80 of set/longjmp() is reset stack pointer to same as the root, and rebuild the data tables (which are now going to be all messed up) from the board representation previously saved at the root. Z80 had an instruction to load and save the SP (I assume 6502 as well, since Ed confirms). Sounds like what you did with Cray Blitz. I forget the details from 1981/2 but you're almost certainly right there was no recursive stack usage, stuff was indexed by ply and saved/loaded from a ply indexed array.

Nevertheless, this argument is not about how horrible jumping out of search is, or how politically incorrect it is to jump anywhere, but whether or not use of ....jmp() implies copying. We say we have used the jumpout ourselves, know others who have done it, and it is therefore not as rare as you claim. Hence can't be used to imply plagiarism.

btw, I assume you consider Fabien to be a really ace programmer? He did produce Fruit after all. He used it, according to you and Zach

Chris Whittington wrote:

zwegner wrote:

BB+ wrote:

Well, in a sense you didn't need to say it because it came across through reading.

You are assuming that the average person read past the first page.

I largely agree with what you say about the ZW analysis.

Here is a list that I came up with (again I rely partially on ZW) of "suspicious" things in Rybka:
* Re-use of exact same File/Rank/Line arrays in PST values (as opposed to an "idea" where statics would be built up in this way, but with different numbers)
* Time management and UCI parsing, particularly the "0.0" appearance
* Copying of the position at the top of the search (Fruit actually copies it back at every iteration), which is pointless as-is in Rybka (it is copied back after the search, again for no reason). Both search 4 ply when a move is forced. [You can also include setjmp under this "Search Start" heading if you like, and I haven't checked whether Rybka actually copies the position, as opposed to Strelka].
* Hash entries: more differences than similarities perhaps, but both start with the same "initial segment" (lock, move, depth, date). The same is true for pawn hash (the size of the entries is not even the same in that case). [Strelka is annoying here, as it does not preserve the Rybka data structures in all cases].
* Great similarity in evaluation. Here the "ideas" concept comes into play. Specific things could be the 1:2:4 weighting of minor:rook:queen (why not 3:5:9?) and the identical minutiae with the DrawBishopFlag -- to offset the former, Fruit has a linear interpolation across phases, while Rybka's is more complicated.
* The use of 10, 30, 60, 100 weighting in passed pawns. If this were a one-off, I could believe the recurrence of this numerology was accidental.

OK, I've needed to look over this again to go over your list, I will probably have some more to add. It will be very much on a as-I-find-the-time basis though. There are a bunch of weird things to add as well--the use of multiple move makers/move generators/move sorters, some of which are more similar to Fruit than others. It's hard to say exactly what happened here though.

Just out of interest, and I'm fairly open on this, although I'ld prefer to keep my rosy view of human nature and that Vas program is quite clean, what are some of the important DIFFERENCES between Fruit and Rybka? Has Vas added stuff, or does your research indicate a straight copy with no significant changes?

Second, what is your view on both the ethics and legality of a parallel development process where the INTENTION is to end up with a piece of work that is entirely self-written, both code and data, but perhaps uses a target program (say Fruit) as a testbed to verify and bugcheck the component functions - having done that, then improve, add, optimise etc. Is that ok in your book, all code and all data different?

CPU wrote:

hyatt wrote: When someone says "There is zero fruit code in Rybka 1" I take the common definition of "zero". 0.000, not "a little" or "not very much".

Where did he say that?

hyatt wrote:

CPU wrote:

hyatt wrote: When someone says "There is zero fruit code in Rybka 1" I take the common definition of "zero". 0.000, not "a little" or "not very much".

Where did he say that?

There have been _several_ such quotes on the Rybka forum. They have occasionally been copied over to CCC.

Rybka is and always was completely original code, with the exception of various low-level snippets which are in the public domain.

CPU wrote:

hyatt wrote:

CPU wrote:

hyatt wrote: When someone says "There is zero fruit code in Rybka 1" I take the common definition of "zero". 0.000, not "a little" or "not very much".

Where did he say that?

There have been _several_ such quotes on the Rybka forum. They have occasionally been copied over to CCC.

I am not trying to be difficult here, but could you point me to one example? I've been searching both forums, and the closest quote I could find is:

Rybka is and always was completely original code, with the exception of various low-level snippets which are in the public domain.

Here he is actually saying that some code is NOT original. Sounds completely honest to me...

JCoit wrote:Bob, I know you don't fulfill requests like this, but could you please have a couple of your grad students produce a 'new' engine using 'snippets of code' from the strongest engines? I'd like to see the ELO you guys could get...could be impressive I'd think.

-James

One can only add the word suspicious if one have checked more programs (say 10-15) and found no such similarities. Perhaps things like these are common in many chess programs. Have Bob, Zach, you, checked 10-15 programs for its absence?

static const int PawnFile[8] = {-3, -1, +0, +1, +1, +0, -1, -3,};
static const int KnightLine[8] = {-4, -2, +0, +1, +1, +0, -2, -4,};
static const int KnightRank[8] = {-2, -1, +0, +1, +2, +3, +2, +1,};
static const int BishopLine[8] = {-3, -1, +0, +1, +1, +0, -1, -3,};
static const int RookFile[8] = {-2, -1, +0, +1, +1, +0, -1, -2,};
static const int QueenLine[8] = { -3, -1, +0, +1, +1, +0, -1, -3,};
static const int KingLine[8] = {-3, -1, +0, +1, +1, +0, -1, -3,};
static const int KingFile[8] = { +3, +4, +2, +0, +0, +2, +4, +3,};
static const int KingRank[8] = { +1, +0, -2, -3, -4, -5, -6, -7,};

Mine has similar values. It's not suspicious at all. [on the 10, 30, 60, 100 scaling]

UCI parsing: perhaps its code is public domain. Fabien took it and so did Vas. Has this option been researched by Zach, Bob and you?

Mine does the same, copy the board before the search starts. It doesn't matter if that is pointless, there are many things in mine that are not in use, they are either remains of previous ideas and forgotten to remove or I leave them there on purpose for future ideas.

I deliberately take the Vas=innocent position for the sake of the discussion.

hyatt wrote:

Chris Whittington wrote:

zwegner wrote:

BB+ wrote:

Well, in a sense you didn't need to say it because it came across through reading.

You are assuming that the average person read past the first page.

I largely agree with what you say about the ZW analysis.

Here is a list that I came up with (again I rely partially on ZW) of "suspicious" things in Rybka:
* Re-use of exact same File/Rank/Line arrays in PST values (as opposed to an "idea" where statics would be built up in this way, but with different numbers)
* Time management and UCI parsing, particularly the "0.0" appearance
* Copying of the position at the top of the search (Fruit actually copies it back at every iteration), which is pointless as-is in Rybka (it is copied back after the search, again for no reason). Both search 4 ply when a move is forced. [You can also include setjmp under this "Search Start" heading if you like, and I haven't checked whether Rybka actually copies the position, as opposed to Strelka].
* Hash entries: more differences than similarities perhaps, but both start with the same "initial segment" (lock, move, depth, date). The same is true for pawn hash (the size of the entries is not even the same in that case). [Strelka is annoying here, as it does not preserve the Rybka data structures in all cases].
* Great similarity in evaluation. Here the "ideas" concept comes into play. Specific things could be the 1:2:4 weighting of minor:rook:queen (why not 3:5:9?) and the identical minutiae with the DrawBishopFlag -- to offset the former, Fruit has a linear interpolation across phases, while Rybka's is more complicated.
* The use of 10, 30, 60, 100 weighting in passed pawns. If this were a one-off, I could believe the recurrence of this numerology was accidental.

OK, I've needed to look over this again to go over your list, I will probably have some more to add. It will be very much on a as-I-find-the-time basis though. There are a bunch of weird things to add as well--the use of multiple move makers/move generators/move sorters, some of which are more similar to Fruit than others. It's hard to say exactly what happened here though.

Just out of interest, and I'm fairly open on this, although I'ld prefer to keep my rosy view of human nature and that Vas program is quite clean, what are some of the important DIFFERENCES between Fruit and Rybka? Has Vas added stuff, or does your research indicate a straight copy with no significant changes?

One obvious one is bitboards vs an array for the board. Which changes the move generator code, evaluation code, make/unmake code, and such. However, A year or so back I re-numbered the bits in my bitboard stuff to get away from the Cray way of numbering starting at the left, and going to the Intel way of starting from the right. It was a _massive_ change. Every evaluation pattern changed. Every move generator changed. Make/Unmake changed. Etc. Was the new version drastically different? Depends on your definition. Comparing lines of code, the changes were enormous. Comparing each idea, everything was identical (indeed, before the change was final, we required exact node count matches on several hundred test positions.)

I would not think that if someone copies Crafty, converts it back to a normal array-based board, that anyone would consider that an original work, even though the code would look wildly different. The analysis would be eerily similar. Changing a data structure does not create a new and original program. There are certainly eval differences, things Vas added or removed. Can someone copy my eval, and then add code and delete code and call this new thing "theirs"?? That's the problem here.

Second, what is your view on both the ethics and legality of a parallel development process where the INTENTION is to end up with a piece of work that is entirely self-written, both code and data, but perhaps uses a target program (say Fruit) as a testbed to verify and bugcheck the component functions - having done that, then improve, add, optimise etc. Is that ok in your book, all code and all data different?

Have not given it much thought. If you mean that we take a program, say Crafty to change the subject, and then write a new move generator to replace the current one, and once debugged, we save it, and then we replace the eval with a new one.. And repeat until everything is new, I suppose that would be perfectly acceptable. Using someone's code during development is not quite the same as using it in the "final product."

If you mean something else, please explain...