What is Fruit? Fabien explains!

[Michael Sherwin]

I promise that I am done now! I really , really have work to do.

In the following quotes you will see that Fabien says that except for a few minor things that do not really affect playing strength that Fruit contains no original algoithms by him. This includes both the search and the evaluation functions. He also claims that the code is lacking any speed tricks. He does claim that his programming style allows the pieces of the program to work better together. What he indicates is (the same thing Tord Romstad says) that writing bug free code is very important to strength.

What I would add is that Fruits evaluation is very good and that is where Fruit gets its main strength. Rybka improved upon this by using the Kauffman statistics. And that is the main difference between Fruit and Rybka. Rybka was also programed to run faster.

Since Fruit contains negligible new original algorithms then there is very little that can be called original work by the author in terms that the GPL, other than the copyright notice, would cover. Fabian admits that Fruit itself is a derivitive work. Derived from sources that have no license and therefore those components can not be licensed in fruit under the GPL. His exact expression (the written code) though is protected by copyright law. In Fruits case the only functions the GPL has is as a copyright notice and to grant you certain freedoms to distribute modified versions under certain restrictions.

Comments by Fabien, taken from Ed Schroeder's web site.

"I can't hide my ideas, but I did not claim I had any of interest either. I prefer to think that I have "principles"; I follow them, whether good or bad. I expect that anybody who had a look at the source code failed to find anything "special" he was looking for ... Perhaps the real idea is that the components in an engine might not be as important as the glue that is tying them (don't look for too much deep meaning in this sentence though)".

"More concretely, in chess that leads to slightly-slower programs (say 25% lower NPS) that are easier to modify. For example Fruit spends a lot of time scanning board squares to evaluate mobility. I know several faster ways I could compute the same thing. However none of them would allow me to easily modify the mobility feature later".

"I should also explain why Bob's code is "less readable" in my opinion. This has nothing to do with poor programming style. Bob has a considerably superior programming experience than I have, and he obviously knows what he is doing. Simply, Crafty's code is full of speed tricks. There is no doubt that it is very fast. Activate both futility pruning and delta pruning in Fruit (Crafty is using both features), and see Fruit's "real" NPS for yourself. Note that these features reduce node count and are slightly beneficial overall, proving once again that NPS is not everything".

"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"".

[Uri Blass]

<snipped>

I promise that I am done now! I really , really have work to do.

In the following quotes you will see that Fabien says that except for a few minor things that do not really affect playing strength that Fruit contains no original algoithms by him. This includes both the search and the evaluation functions. He also claims that the code is lacking any speed tricks. He does claim that his programming style allows the pieces of the program to work better together. What he indicates is (the same thing Tord Romstad says) that writing bug free code is very important to strength.

What I would add is that Fruits evaluation is very good and that is where Fruit gets its main strength.

I disagree with it and I think that Fruit gets it's main strength from
search.

I think that it may be interesting experiment to give fruit the evaluation of other programs(of course not by copy and paste but by replacing the code)

My guess is that fruit with Crafty's evaluation is going to beat Crafty and the same for most other programs.

I do not claim that fruit has not better evaluation than weaker programs but I do not believe that this factor is a dominant factor.

Uri

[Michael Sherwin]

<snipped>

I promise that I am done now! I really , really have work to do.

In the following quotes you will see that Fabien says that except for a few minor things that do not really affect playing strength that Fruit contains no original algoithms by him. This includes both the search and the evaluation functions. He also claims that the code is lacking any speed tricks. He does claim that his programming style allows the pieces of the program to work better together. What he indicates is (the same thing Tord Romstad says) that writing bug free code is very important to strength.

What I would add is that Fruits evaluation is very good and that is where Fruit gets its main strength.

I disagree with it and I think that Fruit gets it's main strength from
search.

I think that it may be interesting experiment to give fruit the evaluation of other programs(of course not by copy and paste but by replacing the code)

My guess is that fruit with Crafty's evaluation is going to beat Crafty and the same for most other programs.

I do not claim that fruit has not better evaluation than weaker programs but I do not believe that this factor is a dominant factor.

Uri

Then do it, if you wish to prove a point!

[Alessandro Scotti]

My guess is that fruit with Crafty's evaluation is going to beat Crafty and the same for most other programs.

Maybe, but will it beat Fruit?

[Uri Blass]

My guess is that fruit with Crafty's evaluation is going to beat Crafty and the same for most other programs.

Maybe, but will it beat Fruit?

My guess is that the answer is negative here.

Note that if it can beat Crafty then it proves that Fruit's search is superior to Crafty's search when the opposite proves nothing because it is possible that some search trick of fruit works with fruit's evaluation and does not work with crafty's evaluation.

Uri

[mjlef]

Wouldn't a simple one ply search match betwwen Crafty and Fruit say who has the better eval? Of course you would have to make sure they both have the same extensions so search does not matter. If anyone does this, let me know the results. I might just try it myself... 1 ply games go very fast!

Mark

[Dave McClain]

<snipped>

I promise that I am done now! I really , really have work to do.

In the following quotes you will see that Fabien says that except for a few minor things that do not really affect playing strength that Fruit contains no original algoithms by him. This includes both the search and the evaluation functions. He also claims that the code is lacking any speed tricks. He does claim that his programming style allows the pieces of the program to work better together. What he indicates is (the same thing Tord Romstad says) that writing bug free code is very important to strength.

What I would add is that Fruits evaluation is very good and that is where Fruit gets its main strength.

I disagree with it and I think that Fruit gets it's main strength from
search.

I think that it may be interesting experiment to give fruit the evaluation of other programs(of course not by copy and paste but by replacing the code)

My guess is that fruit with Crafty's evaluation is going to beat Crafty and the same for most other programs.

I do not claim that fruit has not better evaluation than weaker programs but I do not believe that this factor is a dominant factor.

Uri

Uri,

Stick to the subject, this isn't about whether Fruit can beat Crafy, it'a about Fabien's opinion of what is original and what is not.

[hristo]

...
"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"".

Perfect.
He just made the case that his software is an original work that is fully copyrightable. The ideas employed aren't subject to any sort of protection, but the expression of those ideas is.

In addition he makes the case, it seems, that if one simply studies his code and then develops another chess engine this will not be necessarily a derivative work (of Fruit) since there are so very few original 'ideas' in it. Fruit is a conglomeration of useful technologies, which can be found elsewhere, that one can study and use without inadvertently succumbing to the 'derivative' work category. In this respect Rybka doesn't have to be 'derivative' even if the author never saw the source code of any other chess engine, but Fruit.

Regards and Good morning.

[Uri Blass]

Wouldn't a simple one ply search match betwwen Crafty and Fruit say who has the better eval? Of course you would have to make sure they both have the same extensions so search does not matter. If anyone does this, let me know the results. I might just try it myself... 1 ply games go very fast!

Mark

I do not think that one ply search match can prove which evaluation is better.

The question if some evaluation is better may be dependent on the search algorithm and on the time control.

Note also that I think that speed is also relevant to decide about the quality of evaluation otherwise I can define my evaluation to be result of 10 ply search and have the best evaluation.

My definition of superiority is that evaluation A is superior to evaluation B
if having evaluation A is better in terms of chess results relative to evaluation B.

The only convincing way to demonstrate that fruit's evaluation is better than Crafty's evaluation can be done by implementing fruit's evaluation in Crafty's code and showing that Crafty with fruit's evaluation beat original Crafty.

Uri

[smirobth]

Wouldn't a simple one ply search match betwwen Crafty and Fruit say who has the better eval? Of course you would have to make sure they both have the same extensions so search does not matter. If anyone does this, let me know the results. I might just try it myself... 1 ply games go very fast!

Mark

I do not think that one ply search match can prove which evaluation is better.

The question if some evaluation is better may be dependent on the search algorithm and on the time control.

Note also that I think that speed is also relevant to decide about the quality of evaluation otherwise I can define my evaluation to be result of 10 ply search and have the best evaluation.

My definition of superiority is that evaluation A is superior to evaluation B
if having evaluation A is better in terms of chess results relative to evaluation B.

The only convincing way to demonstrate that fruit's evaluation is better than Crafty's evaluation can be done by implementing fruit's evaluation in Crafty's code and showing that Crafty with fruit's evaluation beat original Crafty.

Uri

I am not a programmer, but it seems to me that evaluation and search cannot be meaningfully separated; that what lines a programmer chooses to extend or prune could be based on his particular evaluation. For example a program with very extensive check extensions might be less inclined to have king safety terms within the evaluation itself.