bhlangonijr wrote:benstoker wrote:That is right. This is a technical forum. That is the point. So please waste no more time denouncing all who question your judgment and in this forum once and for all, offer some TECHNICAL criteria for determining a derivative as opposed to an "original". Proffer will you not TECHNICAL criteria for adding the adjective "impermissible" to the word "derivative". Provide a definition of your word "innovation" as distinguished from eliminating bugs. You say Houdart has not innovated by using the techniques the Critter author described. You say Houdart has not innovated by creating the strongest engine in the world.
But you and LK pick through the code of stockfish and ippo looking for something, something to add to your OWN engine. If you take from ippo, is that "innovation"? Again, give us a set of TECHNICAL criteria to identify impermissible code copying from permissible Idea borrowing. Hyatt has. Why haven't you? It is blatantly hypocritical and atrocious to at once pick through stockfish and ippo on the one hand, and then indict Houdart as a copier, and nothing more than a fine engineer.
If you are the innovator, do turn a blind eye to open source code please.
What you fail to understand is that the "criteria" you are claiming for is only needed when you have a thin line which separates a legal and original program from a non-legal one. If you pick Stockfish or Komodo they are original programs created from scratch, which happens to use some Ippo ideas that worked for them. In the other hand, there is a expert consensus that Houdini was created out of Ippo sources and closed afterwards, a fact that is constantly denied by the "author". That lack of honesty is reason enough to void any positive adjectives one can make about Robert Houdart IMHO.
I was not the one who took this thread down the path of castigating Houdart for not being "innovative" or for having copied the work of others, etc. I hold you to your OWN words and you consistently play dodge ball.
If you want this to be technical, then be technical. That's all I am asking. BE TECHNICAL.
Quit talking out of both sides of your mouths.
To help you fellas out, take a hint from Hyatt, which I requote below for your convenience. If you cannot settle on definition of your terms, then you aint got nothing.
Hyatt:
Code: Select all
While I don't think my old idea of "how much is permissible" is the end-all idea, it is a start.
I have taken the approach to use the following conceptual idea:
If a function that is consistent from input to output, where a move generator is a good example since each position has a fixed number of moves that can be played according to the rules of chess, then perhaps copying that is not a deal-breaker on tournament participation. I can think of other similar pieces of code, such as EGTB probing, where a given position always gives the same answer of mate in N or conversion in N or draw.
Other pieces of code clearly do not follow that concept. An evaluation function is one example. For a given position, there are an infinite number of possible different evaluation outputs. Search also, since one can reduce, extend or prune a move. So those are clearly off-limits. What else?
SEE seems to be the one input one output type of code, with some room for flexibility (do you handle pins, either absolute or not, do you check for legality, etc.) But the options are limited, and one could define, precisely, a SEE() (no pins), or SEEP() (recognizes absolute pins only), SEEAP() which recognizes things like knight pinned on queen by a bishop...
RepetitionCheck()? Rules of chess are quite precise so that might be an ok thing to borrow, although there are quite a few ways to do it (separate hash table, or a repetition list, or something else entirely). But since it is a one input, one output, it seems to fit.
So we are left with the important parts, namely the search (normal and q-search), code that deals with extensions, reductions and pruning, and all the evaluation code. The code that handles time utilization.
What about hashing? Harder case, since this is not a single input -> single output precisely. You can get lots of information from a hash table. A search result. A suggested move. A bound. A hint to avoid doing a null move search. A positional evaluation. Flags such as this was a singular position previously, etc... So maybe hashing is not a one input one output idea, particularly when there are lots of replacement strategies and such.
I think if you apply that question to each function in a chess program, you will find some that are "constant" and some that are "unique". And you might find some one input one output functions inside a non one-input-one-output function. For example, in the evaluation function, you might have a piece of code called HasOpposition(wk, bk, stm). Opposition is well-defined and for any position of the two kings and stm, that function will return T or F. So one might borrow that safely, but not the code where it is used since how you use that could vary all over the place.
One other major point. If you choose to borrow something, which for me would only include the magic move generation stuff (which, by the way does not affect my move generator code at all, I just changed a macro in a very simple way), would be that one must at least provide a proper citation or give credit to the originator of the code that was used. And one would have to abide by the GPL if pieces of a GPL program are borrowed. There is a subtle issue of a GPL program that borrows code from a non-GPL program. That's not supposed to happen, but it does, and it certainly clouds the issue.
The "heart and soul" of a chess engine is the search and evaluation. And copying that code should be a clear no-no. For those one-input-one-output functions, I don't see a problem with them. We already have several common examples. egtb.cpp was originally released as a part of Crafty, written by Eugene Nalimov. Many have used this code. Now MB has released his bitbase stuff and several have used that. Ditto for Pradu's magic move generator idea. Ditto for my rotated bitboard stuff. And we have never seen a program excluded from competition for using those. Nor should we.
There are grey areas such as piece/square tables and others. While there are an infinite number of possible piece/square tables, there are probably fewer than that useful ones. Can someone make a case for any particular piece where there are some obvious numbers and no others make any sense at all? I can't think of one, but that doesn't mean it doesn't exist. Individual scoring numbers? Would two different programmers agree on every scoring term in their evaluation? Can one make a case that fixing one value then dictates the rest if the evaluation is going to be "sane"? Doesn't seem reasonable, but doesn't seem like "impossible" could be proven.
This issue is a very complex one, and it is not going to be a quick and dirty fix I am afraid. It will take some logical/rational discourse and thought to arrive at something that is anywhere near workable.
And now you have answered the question "what is permissible?" That is only the first step, and probably the easiest step although it represents a really significant effort itself. Next is how to validate programs to screen out the bad ones. That is the real can of worms...
