kingliveson wrote:hyatt wrote:I personally believe, as I have stated many times, that this is going to be a long and involved process. First we have to come to grips with some sort of definition of what is allowable and what is not. For example, the ip*/robo*/Ivanhoe/Houdini family. Perhaps it is eventually decided that the "family" is OK. But all can't participate due to the derivative rule in most tournaments. But we have no objective definition of unacceptable derivative vs acceptable derivative. That's got to be ironed. Then the greyer area of what about a program that has parts of another, but not huge chunks?
It appears, to me, that we first need to figure out what is acceptable or unacceptable before we try to start dropping different programs into those two buckets.
[...]
First, Ippolit << RobboLito << Igorrit << IvanHoe are all successive progression of the same engine by the same author(s), just like Cray Blitz to Crafty, though not a translation from one programming language to another -- so this part is easy. Fire (formerly FireBird), Houdini, and Deep Saros should not be difficult to resolve as well. In the case of Fire and Saros, it has been acknowledged by the developers that these are modified Ippolit source code.
It is definitely going to be difficult defining what is acceptable/unacceptable. Fruit/Rybka situation is entirely different than Rybka/Ippolit matter. One deals with alleged code copy while the other is about ideas-- allegedly obtained through reverse engineering. There are those who may even argue that
Assembly to
C is merely a translation.
These are generic questions not directed to you per se, Bob. What amount of code copy if any at all is acceptable? What constitutes an important part or piece of code in a chess engine? With the cat out of the bag in the case of Ippolit source code being public domain, is one allowed to take all ideas found there expressed differently in a new and "original" program? What is the definition of a original chess program in an era where 99% of ideas found in almost all chess engines today are practically the same?
Franklin
I am still a proponent that some code should be copyable. Classic examples include egtb.cpp that many use, and then pradu's magic move generation code (which is even in Crafty). And several have copied the rotated bitboard code from older crafty versions and still use that. If you have some function F, such that F(X) -> Y where for every value of X, you get a single value for Y, then that might well be copyable. This might include any/all of the following (and others I am not listing):
move generator
egtb probe
bitbase probe
SAN Algebraic to binary move input.
binary move output to SAN Algebraic.
PGN parser to pick up the tags, the embedded comments, and such.
Code (such as that in Crafty) that will produce an HTML (rather than PGN) output file to make viewing a game + annotations easier.
Code to properly align malloc() data for optimal cache usage.
Code to produce random numbers used for Zobrist hashing and other uses.
Code to gather/back-up a PV.
...
etc.
There are some such functions that would have to be excluded because of the ill-defined description. For example, if F(X, Y, Z) answers the question "with a white king on X, a black king on Y, and side-to-move of Z, does the white king have opposition?" Should be copyable. The definition is clearly defined with a precise meaning. On the other hand if F(X, Y) answers the question "Is the pawn on square X, given position Y, backward?" then that is not copyable. Because there are lots of definitions of "backward" So some are black, some are white, and some are grey.
I'd think this is the place to start, namely "What can be copied without fear of losing the right to compete in tournaments?" I believe my idea above can be stated precisely enough that we can draw a thin black line, one so thin that either something falls on one side or the other, but never directly on the line where it would be ambiguous...
For example, what about SEE? One can define it to be simple, only using the pieces attacking a square regardless of whether they are pinned or not. Or it could be defined to include absolute pins only (piece pinned on king so that it would be illegal to move it). Or just pinned (knight pinned on rook/queen so that it can move, but at significant cost. This one is debatable. A basic SEE, as used in Crafty, probably should be something that could be copied. Very simple one output for any position and target square. Add complexity and it becomes non-copyable. Or we could stipulate that SEE, SEEAP (abs pins only) and SEEP (all pins) are precisely defined and copyable unless they are further modified to do something else (for example, we could use SEE recursively in SEEP to determine the effect of moving a pinned piece. That would not be copyable).
Complex, but it might be made simple enough to satisfy those of us that deal with software engineering, while still maintaining exclusivity for each "engine core". Search and evaluation would _never_ be copyable since there is no single output of a search since one can use different types of extensions, reductions, and forward/backward pruning ideas, and the eval is wide-open as to what it does...
Those are the basis for the chess engine's "personality" where all the other code supports that personality.
Notice I did not (yet) include book code. That is quite variable, and includes (possibly) different types of learning, different selection rules, and so forth. Perhaps a bare random book code could be copyable. But beyond that bare minimum, you have to "roll your own."
