Crafty accused of copying Fruit PST

[Sven]

I agree with you fully that formulars are not copyrightable, and i add
that reversed engineered ideas,formulas are a matter of interpretation, opinion.
It is not possible to give 100% centainty that what someone interprets is inteded to be the point.

Even if an individual formula isn't copyrightable, if you use 100 formulas and 99 are the same as in another program, that probably is a violation.

If it were as you say, then where would be the borderline? At 50? 10? 90? Why is using one non-copyrightable item no violation but using N+1 non-copyrightable items a copyright violation for some N?

Sounds wrong to me.

Sven

The concept “beyond reasonable doubt”, the criterion on which legal cases are decided in the UK, is sufficiently robust for a jury to handle in a UK criminal case and the concept of “the balance of probability” is sufficiently robust for a judge to handle in a UK civil case.

You express dissatisfaction at the lack of a “borderline”. While you may find the use of concepts that do not have well defined borders to be “wrong”, the workings of legal systems throughout the world are based on them and both lay people and experts are comfortable implementing the two examples listed in my first paragraph.

The criterion on which the impartial experts on the ICGA committee made their decision is not clear but even if it was neither of those two criteria, my opinion, as one who is comfortable using those two criteria, is that the available written analysis constitutes evidence that far surpasses the balance of probability criterion and is almost certainly sufficiently robust to satisfy a jury that worked on the beyond reasonable doubt principle.

Although it has nothing to do with your point, I will add that the behaviour and comments of Vas Rajlich would be seen by both jury and judge to be additional evidence that damages his case.

The discussion points I brought up are challenging the results of the ICGA report and their interpretation. And I am not alone with that. So there IS reasonable doubt. Therefore applying the concept "beyond reasonable doubt" would simply ignore that. I understand your point but I do not agree to your opinion that the written report satisfies the two criteria you mentioned. Non-programmers may get this impression since they do not understand the programming related parts of the report, and may tend to fully believe the summaries and interpretations that are added. The opinions of programmers (outside the panel) about the report, however, seem to be non-uniform.

Sven

[Lusakan]

The concept “beyond reasonable doubt”, the criterion on which legal cases are decided in the UK, is sufficiently robust for a jury to handle in a UK criminal case and the concept of “the balance of probability” is sufficiently robust for a judge to handle in a UK civil case.

Those two concepts are just place holders or shorthand for actual criteria defined in specific terms by the law of evidence. Without the law of evidence they are empty phrases whose meaning is determined arbitrarily. The law of evidence talks about credible witnesses, a smoking gun, a body, a motive and the whole field of admissible and inadmissible evidence on which then a vedict is based.

Sven I think is challenging us to define the criteria that defines theft of code in computer chess. The case at hand is in dispute because the criteria which has been used in the Rybka code theft case is so loose as to be meaningless. Here is a case where no one has a copy of the stolen code to compare with the code from which it has ben stolen. We have been told to test for semantic equivalence as a proxy for the missing code but the distinction between semantic equivalence and ideas is a huge gray area whose boundries are only clear in Bobs head. He is an old man so we need to get it out from him before its too late. To make things worse Michiguel has shown that semantic equivalence can be produced without code theft. Bob now agrees entirely with Michiguel because in Crafty he has been able to independently reproduce a set of 64 numbers from Fruit without copying. If that was a lottery try to compute the probability of winning. Clarifying these things is important because jailing someone for a crime that was undefined when it was committed is not allowed. We have copying of ideas on one end and we have verbatim copying of code at the other end of the same continuum. Then we have someone convicted of none code based "semantic" copying somewhere in the middle. Clearly we need to know where the line is.

[K I Hyams]

I agree with you fully that formulars are not copyrightable, and i add
that reversed engineered ideas,formulas are a matter of interpretation, opinion.
It is not possible to give 100% centainty that what someone interprets is inteded to be the point.

Even if an individual formula isn't copyrightable, if you use 100 formulas and 99 are the same as in another program, that probably is a violation.

If it were as you say, then where would be the borderline? At 50? 10? 90? Why is using one non-copyrightable item no violation but using N+1 non-copyrightable items a copyright violation for some N?

Sounds wrong to me.

Sven

The concept “beyond reasonable doubt”, the criterion on which legal cases are decided in the UK, is sufficiently robust for a jury to handle in a UK criminal case and the concept of “the balance of probability” is sufficiently robust for a judge to handle in a UK civil case.

You express dissatisfaction at the lack of a “borderline”. While you may find the use of concepts that do not have well defined borders to be “wrong”, the workings of legal systems throughout the world are based on them and both lay people and experts are comfortable implementing the two examples listed in my first paragraph.

The criterion on which the impartial experts on the ICGA committee made their decision is not clear but even if it was neither of those two criteria, my opinion, as one who is comfortable using those two criteria, is that the available written analysis constitutes evidence that far surpasses the balance of probability criterion and is almost certainly sufficiently robust to satisfy a jury that worked on the beyond reasonable doubt principle.

Although it has nothing to do with your point, I will add that the behaviour and comments of Vas Rajlich would be seen by both jury and judge to be additional evidence that damages his case.

The discussion points I brought up are challenging the results of the ICGA report and their interpretation. And I am not alone with that. So there IS reasonable doubt. Therefore applying the concept "beyond reasonable doubt" would simply ignore that. I understand your point but I do not agree to your opinion that the written report satisfies the two criteria you mentioned. Non-programmers may get this impression since they do not understand the programming related parts of the report, and may tend to fully believe the summaries and interpretations that are added. The opinions of programmers (outside the panel) about the report, however, seem to be non-uniform.

Sven

The discussion points I brought up are challenging the results of the ICGA report and their interpretation.

I was merely addressing the specific (and important) point in the post to which I replied.

The discussion points I brought up are challenging the results of the ICGA report and their interpretation. And I am not alone with that. So there IS reasonable doubt. Therefore applying the concept "beyond reasonable doubt" would simply ignore that.

You can almost always find experts who challenge evidence. The fact that such people exist does not, in itself, mean that a case fails to meet the beyond reasonable doubt criterion.

Non-programmers may get this impression since they do not understand the programming related parts of the report

Try making such a comment in a court room to a judge and/or a jury and see how far it gets you. I wonder why you are presenting your case in the general forum rather than the programming forum. If it is because you want to educate and inform the jury, you need to do a lot better than that.

The opinions of programmers (outside the panel) about the report, however, seem to be non-uniform.

One of a number of impressions that comes across to me, a man with a basic knowledge of C and a mild interest in the Rajlich affair, is that a dazzling array of the best chess programmers on this planet, including the authors of Fruit and Crafty have associated themselves with the detailed ICGA report. Since then, Miguel scored a very minor hit with his work on PST and a few technically competent others have taken pot shots at it without doing any damage.

[Sven]

Non-programmers may get this impression since they do not understand the programming related parts of the report

Try making such a comment in a court room to a judge and/or a jury and see how far it gets you. I wonder why you are presenting your case in the general forum rather than the programming forum. If it is because you want to educate and inform the jury, you need to do a lot better than that.

I agree that the general forum is not the right place for it, and I think it should continue in the programming forum. This discussion happens to be here for the simple reason that I found two interesting posts by Uri and Julien in the middle of this thread, and replied resp. referred to these. No "education" motives whatsoever. And also no need to imply that.

Sven

[K I Hyams]

The concept “beyond reasonable doubt”, the criterion on which legal cases are decided in the UK, is sufficiently robust for a jury to handle in a UK criminal case and the concept of “the balance of probability” is sufficiently robust for a judge to handle in a UK civil case.

Those two concepts are just place holders or shorthand for actual criteria defined in specific terms by the law of evidence. Without the law of evidence they are empty phrases whose meaning is determined arbitrarily. The law of evidence talks about credible witnesses, a smoking gun, a body, a motive and the whole field of admissible and inadmissible evidence on which then a vedict is based.

“beyond a reasonable doubt adj.
part of jury instructions in all criminal trials, in which the jurors are told that they can only find the defendant guilty if they are convinced "beyond a reasonable doubt" of his or her guilt”
Quote from “TheFreeDictionary”

I understand that the phrase may no longer be used. Either way, it is a vital instruction and one that is clearly considered more meaningful than the implication of your claim: “just place holders or shorthand for actual criteria defined in specific terms by the law of evidence”.

[bob]

While your reply is certainly well thought out, it is simply wrong with respect to copyright law. Copyright law is intended to protect effort, as opposed to text. That is, random text can't be copyrighted, but if something takes effort to produce it, that product can be copyright. And indeed, that has been the metric used in many computer software copyright cases.

The clearest example is that you can not copyright a single PGN game, but you can copyright a collection that took effort to produce. The example often quoted in CC literature is the book with "Fischer's 100 greatest games." That took effort to compile and publish (not forgetting the annotation effort). And it is copyrighted. You want to pin this down to the "OK you can't copyright 1, you can copyright 100, so can you copyright 10, or 30, or 50. I believe that is a decision the court would have to make. If there is no effort required to compile 10 games, I doubt they would uphold a copyright claim. If you took Tal's 10 greatest games and spent a chapter on each annotating each move, yes the court would uphold the copyright claim.

It about the effort, and it is not so easy to say how many evaluation terms one can copy before it is over the "line". For pure source code, the ICGA has simply said "none" without calling the person the code came from part of your team, which excludes him from any other team. Is that the best solution? It is draconian, but it is enforceable as well, which is an advantage. A clear line is always better than a vague one.

However, let's back up a program. What about Rybka 1.6.1 and Crafty? Did you look at that part of the report. It is _really_ revealing about how early "100% original rybka" was anything but original. And it gives insight into the integrity of one that would claim it was 100% original yet absolute proof in the report shows it was simply copied from Crafty 19.x... OK, we have a prior act that was _really_ bad.

Now, on to Fruit/Rybka. What about all of the evidence as a whole, All the PSTs having the same initialization code derivation. The eval similarities. The ugly 0.0 bug in the time management. The iterated search driver that is the same?

One has to draw a line, and there is no way it can be drawn somewhere beyond the point where Rybka/Vas went. He didn't just cross any reasonable line, he crossed the line and kept driving for months.

I don't see any viable explanation that says "this is OK." If it was, one could take any two programs and find enough similarities to make you blink. That doesn't seem to be the case, at least when applied to my code. I've compared fruit's search, Crafty's search, Fruit's basic move selection mechanism against Crafty's, ditto for eval. They don't even look like 10th cousins, much less brother/sister. I don't buy this "all are very similar". It's a thought, but it is not founded on any exhibited data (except for the fruit/rybka case). It appears to me that everyone is trying to use tunnel vision and say "look fruit and rybka are so close because chess algorithms are fairly simple, the range of useful numbers is very small, and speed concerns limit the ways code can be written. To a point where the two programs look so similar, not because they are close derivatives, but because they HAVE to be by the very nature of chess programs. If that is true, one should be able to find a third or fourth program that is not advertised as derived from Fruit, but which still shows those same similarities. To date, no one has offered such evidence to support that theory, and until I see it, I don't buy it. I've looked at a couple of dozen programs over the years, from the 1970 fortran program COKO, to greenblatt's mack hack pdp 10 assembly code, to Slate's chess 4.x CDC assembly code, to Cray Blitz (of course) to Chaos, to LaChex (Los Alamos program) to today's current group of open-source programs. And I don't see just one overall design, with similar code. I see lots of different ways to implement each and every thing required to create a chess program.

Simple things. Compare SEE. Move ordering ideas. Evaluation concepts, scores, and exact methodology. This idea of "just a very few ways" to do these things doesn't jive with reality. Maybe in a few small cases, sure. But not across a wide slice of a chess engine...

That's where I have the problem with these ideas.

[Sven]

While your reply is certainly well thought out, it is simply wrong with respect to copyright law. Copyright law is intended to protect effort, as opposed to text. That is, random text can't be copyrighted, but if something takes effort to produce it, that product can be copyright. And indeed, that has been the metric used in many computer software copyright cases.

The clearest example is that you can not copyright a single PGN game, but you can copyright a collection that took effort to produce. The example often quoted in CC literature is the book with "Fischer's 100 greatest games." That took effort to compile and publish (not forgetting the annotation effort). And it is copyrighted. You want to pin this down to the "OK you can't copyright 1, you can copyright 100, so can you copyright 10, or 30, or 50. I believe that is a decision the court would have to make. If there is no effort required to compile 10 games, I doubt they would uphold a copyright claim. If you took Tal's 10 greatest games and spent a chapter on each annotating each move, yes the court would uphold the copyright claim.

It about the effort, and it is not so easy to say how many evaluation terms one can copy before it is over the "line". For pure source code, the ICGA has simply said "none" without calling the person the code came from part of your team, which excludes him from any other team. Is that the best solution? It is draconian, but it is enforceable as well, which is an advantage. A clear line is always better than a vague one.

However, let's back up a program. What about Rybka 1.6.1 and Crafty? Did you look at that part of the report. It is _really_ revealing about how early "100% original rybka" was anything but original. And it gives insight into the integrity of one that would claim it was 100% original yet absolute proof in the report shows it was simply copied from Crafty 19.x... OK, we have a prior act that was _really_ bad.

Now, on to Fruit/Rybka. What about all of the evidence as a whole, All the PSTs having the same initialization code derivation. The eval similarities. The ugly 0.0 bug in the time management. The iterated search driver that is the same?

One has to draw a line, and there is no way it can be drawn somewhere beyond the point where Rybka/Vas went. He didn't just cross any reasonable line, he crossed the line and kept driving for months.

I don't see any viable explanation that says "this is OK." If it was, one could take any two programs and find enough similarities to make you blink. That doesn't seem to be the case, at least when applied to my code. I've compared fruit's search, Crafty's search, Fruit's basic move selection mechanism against Crafty's, ditto for eval. They don't even look like 10th cousins, much less brother/sister. I don't buy this "all are very similar". It's a thought, but it is not founded on any exhibited data (except for the fruit/rybka case). It appears to me that everyone is trying to use tunnel vision and say "look fruit and rybka are so close because chess algorithms are fairly simple, the range of useful numbers is very small, and speed concerns limit the ways code can be written. To a point where the two programs look so similar, not because they are close derivatives, but because they HAVE to be by the very nature of chess programs. If that is true, one should be able to find a third or fourth program that is not advertised as derived from Fruit, but which still shows those same similarities. To date, no one has offered such evidence to support that theory, and until I see it, I don't buy it. I've looked at a couple of dozen programs over the years, from the 1970 fortran program COKO, to greenblatt's mack hack pdp 10 assembly code, to Slate's chess 4.x CDC assembly code, to Cray Blitz (of course) to Chaos, to LaChex (Los Alamos program) to today's current group of open-source programs. And I don't see just one overall design, with similar code. I see lots of different ways to implement each and every thing required to create a chess program.

Simple things. Compare SEE. Move ordering ideas. Evaluation concepts, scores, and exact methodology. This idea of "just a very few ways" to do these things doesn't jive with reality. Maybe in a few small cases, sure. But not across a wide slice of a chess engine...

That's where I have the problem with these ideas.

Bob,
I was talking about "reuse of evaluation concepts", not about general copyright questions. Also not about chess games and PGN files. We are in the domain of software. I can understand your intention to compare "copying of 100 chess games" somehow to software in order to discuss that "draw a borderline" point. But no, it simply does not apply to the point I am making. There is nothing comparable to the "evaluation concepts" that could be free of copyright in the domain of "large collections of chess games". From the (assumed) fact that copying a collection of 100 games violates copyright (if a judge decides so) you can't derive that partially reusing 30 evaluation concepts violates it, too. Apples and oranges.

If we declare reusing many eval concepts as illegal then virtually all chess engines are illegal. And if we declare 44% eval feature overlap as legal but 74% (following the quite subjective numbers of Mark Watkins since we have nothing better) as illegal then this is not comprehensible for anyone. You did not address these two central points of my previous posts, for obvious reasons.

And I was also talking about the Fruit/Rybka case. Rybka 1.6.1 is irrelevant for the ICGA, for the FSF, and for computer chess today, even if there is no doubt that it contained some Crafty code. So please stay on topic. I can understand that you are "not amused" regarding that 1.6.1 case from the past, and I am not saying that Vas were innocent w.r.t. early pre-1.0beta Rybka. But please do not mix it with the relevant part about Fruit/Rybka.

Also nobody has ever stated that Crafty and Fruit had big similarities, so even that part of your post is fully off-topic. Same for the related section about "different overall design of various chess programs", that is simply unrelated to what I wrote, nothing but noise.

Prepared for more obfuscations,
Sven

[Desperado]

While your reply is certainly well thought out, it is simply wrong with respect to copyright law. Copyright law is intended to protect effort, as opposed to text. That is, random text can't be copyrighted, but if something takes effort to produce it, that product can be copyright. And indeed, that has been the metric used in many computer software copyright cases.

The clearest example is that you can not copyright a single PGN game, but you can copyright a collection that took effort to produce. The example often quoted in CC literature is the book with "Fischer's 100 greatest games." That took effort to compile and publish (not forgetting the annotation effort). And it is copyrighted. You want to pin this down to the "OK you can't copyright 1, you can copyright 100, so can you copyright 10, or 30, or 50. I believe that is a decision the court would have to make. If there is no effort required to compile 10 games, I doubt they would uphold a copyright claim. If you took Tal's 10 greatest games and spent a chapter on each annotating each move, yes the court would uphold the copyright claim.

It about the effort, and it is not so easy to say how many evaluation terms one can copy before it is over the "line". For pure source code, the ICGA has simply said "none" without calling the person the code came from part of your team, which excludes him from any other team. Is that the best solution? It is draconian, but it is enforceable as well, which is an advantage. A clear line is always better than a vague one.

However, let's back up a program. What about Rybka 1.6.1 and Crafty? Did you look at that part of the report. It is _really_ revealing about how early "100% original rybka" was anything but original. And it gives insight into the integrity of one that would claim it was 100% original yet absolute proof in the report shows it was simply copied from Crafty 19.x... OK, we have a prior act that was _really_ bad.

Now, on to Fruit/Rybka. What about all of the evidence as a whole, All the PSTs having the same initialization code derivation. The eval similarities. The ugly 0.0 bug in the time management. The iterated search driver that is the same?

One has to draw a line, and there is no way it can be drawn somewhere beyond the point where Rybka/Vas went. He didn't just cross any reasonable line, he crossed the line and kept driving for months.

I don't see any viable explanation that says "this is OK." If it was, one could take any two programs and find enough similarities to make you blink. That doesn't seem to be the case, at least when applied to my code. I've compared fruit's search, Crafty's search, Fruit's basic move selection mechanism against Crafty's, ditto for eval. They don't even look like 10th cousins, much less brother/sister. I don't buy this "all are very similar". It's a thought, but it is not founded on any exhibited data (except for the fruit/rybka case). It appears to me that everyone is trying to use tunnel vision and say "look fruit and rybka are so close because chess algorithms are fairly simple, the range of useful numbers is very small, and speed concerns limit the ways code can be written. To a point where the two programs look so similar, not because they are close derivatives, but because they HAVE to be by the very nature of chess programs. If that is true, one should be able to find a third or fourth program that is not advertised as derived from Fruit, but which still shows those same similarities. To date, no one has offered such evidence to support that theory, and until I see it, I don't buy it. I've looked at a couple of dozen programs over the years, from the 1970 fortran program COKO, to greenblatt's mack hack pdp 10 assembly code, to Slate's chess 4.x CDC assembly code, to Cray Blitz (of course) to Chaos, to LaChex (Los Alamos program) to today's current group of open-source programs. And I don't see just one overall design, with similar code. I see lots of different ways to implement each and every thing required to create a chess program.

Simple things. Compare SEE. Move ordering ideas. Evaluation concepts, scores, and exact methodology. This idea of "just a very few ways" to do these things doesn't jive with reality. Maybe in a few small cases, sure. But not across a wide slice of a chess engine...

That's where I have the problem with these ideas.

Hello Bob,

that is the most liberal explenation, argumentation i was able to read from
you, so far (of course i did not read every post on this topic you ever posted somewhere).

So, i want to give you my thoughts about that. If i look at my own engine,
that i consider as original work, i acertain the following facts:

My general design is certainly unique, but with the great number of open
sources there might be people seeing similarities from engine x or y, especially in the detail section.
More and more public domain code will be included in future.
There a more chess programs/programmers than ever before.
Now, because of that fact, there will be even more similarties than ever
before.Today, especially top programs converge in elected parts of the
technical choice of implementation (like the use of magics).
Chess programs are really fragmented in little chunks today.
Of course there will ever be room for implementation details.
But a lot of implemented features in the detail section are close to 100% efficient and are very hard to improve or to change somehow.
(take the mobility feature for bitboards, popcnt * constant). Yes one can
improve and change such a concept, but it will also add code complexity.
And here the maths of the programmer begins, with the question: keep
it simple and stupid or change it for a very,very good reason. There are
many features of this category.
The same for code chunks. Recently some threads appeared in the
programm/technical section here about SEE implementation.Well, my
SEE code is based on the pseudo code given from chessprogramming-wiki, which perfectly matched my datastructures. I am pretty sure
this code chunk will appear in a lot of different engines. If you read
2 engines not knowing this is public domain code, someone will cry again
copy,clone etc... When you look at it, you will realize that such code
is very compact,fast and as long you do not want to trade accuracy for
speed, there hardly wont be, maybe cannot be _big_ changes.
Let us say, i dont pick it up from chessprogramming-wiki, but from another engine and give it a try to improve it like i did. It was one line,
but changing the algorithm, what is it now ? copying ? what is if the
effort is lower than the effect ?
Another question is, why are programmers more liberal in copying parts
of the technical section like magic numbers, but go crazy with pst values.
It is at least debatable.
I also give my best to be author of a "100%" original work,but it is with the
mathematical definition of 100% not possible. I assure you that _every_ formular,concept i use, is tested against 3-10 own ideas and public known ideas,
formulars,concepts. If i want to be my engine competitive, i also
have to accept ideas,formulars found by others. I am not perfect, so
sometimes the inspiration given from other authors, or subtle progress
from chess programmers community, is superior. Accepting this is part
of making progress, and no human on this planet can reinvent all wheels.
Even if, no human can improve all wheels.
(eg: my engine uses the same/similar basic concept for kingSafty/pieceAttacks like Fruit is doing,
but of course with own implementation and different values, because i use bitboards. With respect to code complexity and performance it is hard to do better.
Receiving phD is no requirement for such a formular. Which is another problem with easy formulars,
you cannot forbid sth like that because it already exists. Should i now feel bad ?
eg: i recently decided to see what will happen if i split the search
into several parts (all,cut,pv,whatever type of node). Not because the robo
familiy is doing so, but because i want to explore the possibilities. And
i guarantee to keep it when i find a reason which is profitable to do so.
)

So please, get me right. I _dont_ say you are wrong in any way. But the
thing with _nature_ of chess programming and similarities will certainly match more with my reasoning in the _upcoming_ years.
More public domain solutions, more of them with efficiency getting closer to the maximum and finally the competition aspect to use them in a legal way.

I will add at this point that my engine is privat, because my goal is to release it at stable 3000 elo. (current level is about 2950).
I know as you know how much time it takes when writing an engine from scratch, looping
over it again and again. This is now my hobby from the day i wrote the "hello world" program. But especially the last 3 years i progressed on
and invested a lot of time. Over all these years it summed together, easily
thousands of hours. The problem is, that people finally only see what is
left, but not what you sorted out over the years which is the main work.
Once this is done, i can rewrite my engine within 2 weeks.
So,they only get the tip of the iceberg.
And now my point: if there will be similarities to engines ( i may even do not know),
i can speak at least for myself,
that i _dont want to_ accept your arguments referenced to myself.
Uncouth spoken (not mathematical), I consider my engine as 100% original.
(but think of the case, today would appear another 3000 engine...)

So i hope your opinion is not a generalization of what is right/wrong,
you may hit the wrong groups. You dont only have an opinion, as
expert you also make opinions.

regards, Michael

[Desperado]

EDIT:

Uncouth spoken (not mathematical), I consider my engine as 100% original.

(but think of the case, today would appear another 3000 engine
in a _first_ release version, by a chessprogrammer never heard
before...)

[Sven]

Hello Bob,

that is the most liberal explenation, argumentation i was able to read from
you, so far (of course i did not read every post on this topic you ever posted somewhere).

So, i want to give you my thoughts about that. If i look at my own engine,
that i consider as original work, i acertain the following facts:

My general design is certainly unique, but with the great number of open
sources there might be people seeing similarities from engine x or y, especially in the detail section.
More and more public domain code will be included in future.
There a more chess programs/programmers than ever before.
Now, because of that fact, there will be even more similarties than ever
before.Today, especially top programs converge in elected parts of the
technical choice of implementation (like the use of magics).
Chess programs are really fragmented in little chunks today.
Of course there will ever be room for implementation details.
But a lot of implemented features in the detail section are close to 100% efficient and are very hard to improve or to change somehow.
(take the mobility feature for bitboards, popcnt * constant). Yes one can
improve and change such a concept, but it will also add code complexity.
And here the maths of the programmer begins, with the question: keep
it simple and stupid or change it for a very,very good reason. There are
many features of this category.
The same for code chunks. Recently some threads appeared in the
programm/technical section here about SEE implementation.Well, my
SEE code is based on the pseudo code given from chessprogramming-wiki, which perfectly matched my datastructures. I am pretty sure
this code chunk will appear in a lot of different engines. If you read
2 engines not knowing this is public domain code, someone will cry again
copy,clone etc... When you look at it, you will realize that such code
is very compact,fast and as long you do not want to trade accuracy for
speed, there hardly wont be, maybe cannot be _big_ changes.
Let us say, i dont pick it up from chessprogramming-wiki, but from another engine and give it a try to improve it like i did. It was one line,
but changing the algorithm, what is it now ? copying ? what is if the
effort is lower than the effect ?
Another question is, why are programmers more liberal in copying parts
of the technical section like magic numbers, but go crazy with pst values.
It is at least debatable.
I also give my best to be author of a "100%" original work,but it is with the
mathematical definition of 100% not possible. I assure you that _every_ formular,concept i use, is tested against 3-10 own ideas and public known ideas,
formulars,concepts. If i want to be my engine competitive, i also
have to accept ideas,formulars found by others. I am not perfect, so
sometimes the inspiration given from other authors, or subtle progress
from chess programmers community, is superior. Accepting this is part
of making progress, and no human on this planet can reinvent all wheels.
Even if, no human can improve all wheels.
(eg: my engine uses the same/similar basic concept for kingSafty/pieceAttacks like Fruit is doing,
but of course with own implementation and different values, because i use bitboards. With respect to code complexity and performance it is hard to do better.
Receiving phD is no requirement for such a formular. Which is another problem with easy formulars,
you cannot forbid sth like that because it already exists. Should i now feel bad ?
eg: i recently decided to see what will happen if i split the search
into several parts (all,cut,pv,whatever type of node). Not because the robo
familiy is doing so, but because i want to explore the possibilities. And
i guarantee to keep it when i find a reason which is profitable to do so.
)

So please, get me right. I _dont_ say you are wrong in any way. But the
thing with _nature_ of chess programming and similarities will certainly match more with my reasoning in the _upcoming_ years.
More public domain solutions, more of them with efficiency getting closer to the maximum and finally the competition aspect to use them in a legal way.

I will add at this point that my engine is privat, because my goal is to release it at stable 3000 elo. (current level is about 2950).
I know as you know how much time it takes when writing an engine from scratch, looping
over it again and again. This is now my hobby from the day i wrote the "hello world" program. But especially the last 3 years i progressed on
and invested a lot of time. Over all these years it summed together, easily
thousands of hours. The problem is, that people finally only see what is
left, but not what you sorted out over the years which is the main work.
Once this is done, i can rewrite my engine within 2 weeks.
So,they only get the tip of the iceberg.
And now my point: if there will be similarities to engines ( i may even do not know),
i can speak at least for myself,
that i _dont want to_ accept your arguments referenced to myself.
Uncouth spoken (not mathematical), I consider my engine as 100% original.
So i hope your opinion is not a generalization of what is right/wrong,
you may hit the wrong groups.

regards, Michael

Hi Michael,

[breaking my promise to leave this thread, hopefully for the last time ...]

your thoughts are quite similar to mine but I think you expressed them much better than I did it before. I can fully agree to all of your points, with the only restriction that the term "public domain" you have used should certainly be replaced by "open source". Thank you for sharing your very interesting and (IMO) very important view.

You have definitely increased the probability to convince Bob from 0.0009% to 0.001%

Looking forward to your release of the new no. 20 (10? 3? 1?) engine in the world

Btw, since currently Crafty is at 2951 ELO in CCRL 40/40 you might decide to already release your engine when it has 2952 That might take away another digit behind the decimal point from the probability given above ...

Sven