Interesting reflection on a past statement

[Graham Banks]

I found this posted here back in 2008. Thought it was interesting considering what has transpired in recent times.

http://www.top-5000.nl/int/fruit.htm

"...I am sorry to say that whether an engine is someone's "own work" makes little sense to me, although I understand that tournament directors would like a clear yes or no.

The reason is that all engines, whether amateur or commercial, share most of the techniques. Alpha-beta (of which PVS, NegaScout and MTD(f) are only derivatives), iterative deepening, check extensions, null move, etc ... are shared by most and have been published, mostly by researchers, some of them more than 30 years ago! Sure there are many different ways to represent the board and pieces but it only affects speed, which rarely amounts to more than a few dozen Elo Points.

There is one component that so far is distinct in each engine (although some older ones were probably "inspired" by Crafty): the evaluation function. But there again the evaluation features are hardly ever very original: the principles of sound chess play can be found in hundreds of books. It's hardly a secret that rooks should be placed on open files, something that Fruit does not even know (though rook mobility partly emulates this piece of knowledge).

So what is left for improvisation? A lot of course, otherwise all engines would be equal. But say in terms of quantity of code they don't represent so much. Among this "lot" I think there is a large place for things that cannot be extracted: programming style and ways of linking engine components, making them work together. Not something that most would consider as a "chess-engine technique" like null move.

OK let's stop here and do a little sum up with Fruit in mind: I can't think of a search feature in it that was not described before. Ditto for evaluation terms (except perhaps a few drawish-endgame rules that activate in one game in a hundred). There are specific principles that I follow in Fruit that gives it a personality somewhat (like never truncating the PV and making sure that mate-depth claims are always correct), but they probably have no impact on strength at all and could even hurt a little.

Can I claim that I have written it all on my own? "Yes", I typed all the code myself. Without help??? Certainly not, hence my point: "it makes no sense".

Sorry for the dramatic style ... One positive point now: instead of seeing engine authors competing against each others, I see them as cooperating (mostly indirectly) and making progress together, since they have so much in common, whether they want it or not.

My opinion anyway ... "

[Gerd Isenberg]

Graham, this statement is about using ideas and algorithms, where you have zillions ^ zillion possible ways to implement stuff, and not about taking an open source program to translate already implemented ideas only to make it conform to own data structures, and then to do some modifications.

Gerd

[Ferdy]

I found this posted here back in 2008. Thought it was interesting considering what has transpired in recent times.

http://www.top-5000.nl/int/fruit.htm

"...I am sorry to say that whether an engine is someone's "own work" makes little sense to me, although I understand that tournament directors would like a clear yes or no.

The reason is that all engines, whether amateur or commercial, share most of the techniques. Alpha-beta (of which PVS, NegaScout and MTD(f) are only derivatives), iterative deepening, check extensions, null move, etc ... are shared by most and have been published, mostly by researchers, some of them more than 30 years ago! Sure there are many different ways to represent the board and pieces but it only affects speed, which rarely amounts to more than a few dozen Elo Points.

There is one component that so far is distinct in each engine (although some older ones were probably "inspired" by Crafty): the evaluation function. But there again the evaluation features are hardly ever very original: the principles of sound chess play can be found in hundreds of books. It's hardly a secret that rooks should be placed on open files, something that Fruit does not even know (though rook mobility partly emulates this piece of knowledge).

So what is left for improvisation? A lot of course, otherwise all engines would be equal. But say in terms of quantity of code they don't represent so much. Among this "lot" I think there is a large place for things that cannot be extracted: programming style and ways of linking engine components, making them work together. Not something that most would consider as a "chess-engine technique" like null move.

OK let's stop here and do a little sum up with Fruit in mind: I can't think of a search feature in it that was not described before. Ditto for evaluation terms (except perhaps a few drawish-endgame rules that activate in one game in a hundred). There are specific principles that I follow in Fruit that gives it a personality somewhat (like never truncating the PV and making sure that mate-depth claims are always correct), but they probably have no impact on strength at all and could even hurt a little.

Can I claim that I have written it all on my own? "Yes", I typed all the code myself. Without help??? Certainly not, hence my point: "it makes no sense".

Sorry for the dramatic style ... One positive point now: instead of seeing engine authors competing against each others, I see them as cooperating (mostly indirectly) and making progress together, since they have so much in common, whether they want it or not.

My opinion anyway ... "

I'd like to know a programmer who has not read open source codes, does not read the forums, does not read computer chess programming books, will not do RE and write his own chess program, will that qualify to be an original program? And would then claim to be 100% own's work?

[hgm]

Well, "own work" is obviously a continuous function, running from an infinitesimal change to a downloaded open-source code to locking yourself away on an island and trying to re-invent minimax. As allowing the first would lead to an unworkable situation, and we don't want people to do the second, we must put a limit somewhere in between those extremes, and where exactly we put is it in a sense arbitrary.

There is code, there are algorithms, and there are ideas. Resticting the use of ideas is not useful. (E.g. organize a car race, where the participants are not allowed to use round wheels, because Mercedes already used those, but have to limit themseves to other geometric shapes.) And unfortunately the boundary between ideas and algorithms is not very sharp, as many of the ideas are in fact (loosely specified) algorithms.

So the standard we apply is that when there are many different ways a loosely specified algorithm can be precisely specified, and they are all approximately equivalent, using that exact same algorithm would not be allowed. Because it is something that could be done with a mindless copier, that knows how to program, but has no clue whatsoever as to what the algorithm does, or why.

[Adam Hair]

Graham, this statement is about using ideas and algorithms, where you have zillions ^ zillion possible ways to implement stuff, and not about taking an open source program to translate already implemented ideas only to make it conform to own data structures, and then to do some modifications.

Gerd

Hi Gerd,

Many people, including some engine authors, fail to make this distinction.

Here is an analogy that seems appropriate in describing the distinction:

All engine authors are like art students assigned the same still life subject, say a vase of flowers (NOT FRUIT!!! ), which represents the ideal chess engine. The ideas and algorithms can be likened to the different colors of paint on their palette. Each painter/author has the same colors to work with. However, their abilities and tools differ, as well as their perception of the vase of flowers. Thus, their still life paintings will all differ. The hues of the colors will not be exactly the same. Certain aspects will stand out more in one painting than another painting. Some paintings will be more visually appealing. Now, an painter/author can study the work of another painter/author that they feel is superior in order to learn how to paint/code better. If some master describes the colors and techniques they used, it makes sense for the ones with less ability and/or talent to study this description in order to improve, to paint/write a better still life/engine.

However, some use open source engines as a paint-by-the-numbers canvas. The outline of the features and the colors to use were worked out by somebody else. Even if you add flourishes to it, the hardest work, or at least the dullest, was done by somebody else.

[sje]

I found this posted here back in 2008. Thought it was interesting considering what has transpired in recent times.

http://www.top-5000.nl/int/fruit.htm

"Alpha-beta (of which PVS, NegaScout and MTD(f) are only derivatives), iterative deepening, check extensions, null move, etc ... are shared by most and have been published, mostly by researchers, some of them more than 30 years ago! "

Some of us posting here today had working chess programs more than thirty years ago. Maybe not very good ones, but all done more than a decade before the beginning of the web.

[Rebel]

Graham, this statement is about using ideas and algorithms, where you have zillions ^ zillion possible ways to implement stuff, and not about taking an open source program to translate already implemented ideas only to make it conform to own data structures, and then to do some modifications.

Hi Gerd,

You make an interesting statement. IMO the accusation stands or falls if it can be proven beyond reasonable doubt that Vas took the Fruit sources as WHOLE, modified it and called the end-result (R1) his OWN.

If I understand your choice of words right you suggest another (guilty) scenario. That Vas had an OWN engine, learned a lot from Fruit how to do things right and then took many things, but wrote his own CODE nevertheless.

Have I understood you correct so far ?

Ed

[hgm]

Fortunately it is utterly irrelevant which guilty scenario applies to Vas,if indeed any applies at all. Vas is guilty by default, as he failed to comply with the rules that stated he should have supplied source code on request. End of story. No need to (re-re-re-)discuss it at nauseam here...

As long as someone does not supply source code, there will always be doubt. And as long as there is doubt, he is guilty!

[Rebel]

as he failed to comply with the rules that stated he should have supplied source code on request.

Vas was never asked to hand-over his source code.

[hgm]

Then he should appeal based on that. Still not our concern.