Interesting excerpt from Fabien Letouzey interview

[Graham Banks]

Seems FSF is now the owner of Fruit code so this may be moot anyway...

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

[swami]

Fabien Letouzey Wrote:

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.

Yes, I like the idea of group of programmers co-operating and working together to bring in the strongest engine on the planet

Only Toga project has a few group of programmers but It doesn't seem like these group of people updating Toga are exactly co-operating and working together in emails.We see only the single version from one person, and other version from someone else etc

[kranium]

Fabien Letouzey Wrote:

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.

Yes, I like the idea of group of programmers co-operating and working together to bring in the strongest engine on the planet

Only Toga project has a few group of programmers but It doesn't seem like these group of people updating Toga are exactly co-operating and working together in emails.We see only the single version from one person, and other version from someone else etc

yes i agree...this is interesting.
i too like the idea.

if all this 'toga mara' stuff is true, (as it appears it might be),
toga would then be a lot closer to rybka in strength and provide some needed competition...
was said to be a 100-200 ELO point improvement, and beating v2.3.2?

that would be a very welcome development indeed...

[Eelco de Groot]

yes i agree...this is interesting.
i too like the idea.

if all this 'toga mara' stuff is true, (as it appears it might be),
toga would then be a lot closer to rybka in strength and provide some needed competition...
was said to be a 100-200 ELO point improvement, and beating v2.3.2?

that would be a very welcome development indeed...

Please don't get Zach started on this. I can already imagine 200 pages long threads, disassembly listings, Europol, ICCA meetings, public e-mail exchanges and other stuff this forum thrives on.

An excerpt of the code dissection by Zach I can already give:

"You see this is the part of the code where Toga Mara is counting Kings. The side with more than one King can get a tactical bonus if it also fulfills 444 other conditions which are all placed on one line, to improve readiblity for inexperienced programmers. The counting of Kings has to do with King affinity and processing speed. The program, triggered by counting wk >= bk, starts fetching the data with all material values but because the first condition is always true this enables very efficient branch prediction in the pipeline. Especially helpful on the newest Nehalem architectures with hyperthreading, so most users can not directly see the benefit of this. Yes, I too was a bit sceptical but now I'm a believer too. A revelation descended on me when Tam told us that we have yet to learn a lot about C. Apparently only Vas and Tam understand chess programming and have mastered programming C++, it is simple really, I read his code and now I understand"

Please also don't take this too literally, it was a nice try and not altogether without merit.

Belka 1.8.11 - Toga Mara Beta/Toga II Checkov Beta_4: 7 - 5

Eelco

[kranium]

i'm not sure what this means Eelco...can you put it in a nutshell?

i.e. Belka is stronger than Mara?

[Eelco de Groot]

i'm not sure what this means Eelco...can you put it in a nutshell?

i.e. Belka is stronger than Mara?

Too few games to say that, and it is not really Toga Mara because so far there was only a material.cpp codefragment we got from the mysterious programmer. I modified the code, otherwise I don't see how it could work well but I did not really test the original material.cpp. I am also not sure how a regular Toga would do against this old Belka 1.8.11 version, it is the only Belka I have and I played it against Glaurung more often, not against Togas. Glaurung can get into big trouble against all the Rybka clones and this Belka gave older Glaurung betas not much chance in the past, Toga does better in general but if you ask me for a single reason why this is so I do not know it. But to me the difference in performances against Rybka code is not a good indication of the real strength difference between Glaurung and Toga. I'm testing on older hardware too etc. But this Belka 1.8.11 is certainly not weak, this result is about what I would expect for any Toga version that we now have. Not a big improvement, the code also does not seem to "break" anything in my test but then Jerry had much worse results, maybe he tested it with the original material.cpp.

Eelco

[ernest]

Seems FSF is now the owner of Fruit code so this may be moot anyway...
http://www.top-5000.nl/int/fruit.htm

Interesting interview, but how old is it: 2 years? 5 years? 20 years?

[GenoM]

Belka 1.8.18 is the strongest so far. About +35 Elo above Belka 1.8.11.

[bob]

Seems FSF is now the owner of Fruit code so this may be moot anyway...

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

And that is all nonsense, again. Similar algorithms does _not_ translate into similar code. I can't, for the life of me, imagine why anyone with any programming experience at all would keep raising this bogus point of view. It is simply nonsense. In my programming classes, I often wish it _was_ true, so that I would not have to look at so many different ways to do the same thing.

[bob]

Seems FSF is now the owner of Fruit code so this may be moot anyway...

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

That is the purpose of the GPL. Not to stifle development, but to _accelerate_ it. But at the same time eliminating the human nature to take what is good, but not give back anything. So if you borrow GPL code, that is perfectly legal, so long as you give back your code for others to build on.

It is _not_ a "you can't use this code" deal, it is a "if you use what others have shared, you have to share also."

And again, for _any_ algorithm, there are an infinite (and yes, I do mean infinite) number of ways to express that algorithm. See "regular expressions" for how there are an infinite number of ways to express a single line of code, in fact.