TalkChess.com

Graham Banks wrote:

Michael Diosi wrote:Sorry, the fact that Zach is saying he looke d at it found out that is not a proof either, it's a statement.


I will publish all the ncessary info at the Arena page:

http://www.playwitharena.com

I'm not agreeing one way or the other at present because I'm not a programmer. However, I thought that the moderators had agreed that clone claims were not allowed in CCC without proof being posted here to back up the claim.

Cheers,
Graham.

Michael Diosi wrote:

Guenther wrote:

Graham Banks wrote:

Michael Diosi wrote:Sorry, the fact that Zach is saying he looke d at it found out that is not a proof either, it's a statement.


I will publish all the ncessary info at the Arena page:

http://www.playwitharena.com

I'm not agreeing one way or the other at present because I'm not a programmer. However, I thought that the moderators had agreed that clone claims were not allowed in CCC without proof being posted here to back up the claim.

Cheers,
Graham.

I don't know what all the fuzz is about. The 'author' of Protector himself
announced it as a derivative and as he also mentioned the origin of it
and published the source I see no need neither to defend nor to abolish it.
So what 'proof' for what should be given at all? It is just not what was
called an original program in the past.
(If someone is too sensible to be called a clone programmer or derivative
programmer he just should start the harder way and not from a given 2700+
open source program. BTW I would like to see what he had 6 years ago - I bet there was nothing...)

Guenther

BTW it is very unpleasant that the current discussion is completely
away from the original topic! Since dozens of posts there is no talk
about N.S. aka Kranium, which is a very different case and I guess
the thread should be split.

Guenther wrote:
I don't know what all the fuzz is about. The 'author' of Protector himself
announced it as a derivative and as he also mentioned the origin of it
and published the source I see no need neither to defend nor to abolish it.
So what 'proof' for what should be given at all?

Michael Diosi wrote:Cred ca nici acum n-ai inteles. Ce s-a mai ales si din Iasiul ala...

Uri Blass wrote:

Guenther wrote:

Graham Banks wrote:

Michael Diosi wrote:Sorry, the fact that Zach is saying he looke d at it found out that is not a proof either, it's a statement.


I will publish all the ncessary info at the Arena page:

http://www.playwitharena.com

I'm not agreeing one way or the other at present because I'm not a programmer. However, I thought that the moderators had agreed that clone claims were not allowed in CCC without proof being posted here to back up the claim.

Cheers,
Graham.

I don't know what all the fuzz is about. The 'author' of Protector himself
announced it as a derivative and as he also mentioned the origin of it
and published the source I see no need neither to defend nor to abolish it.
So what 'proof' for what should be given at all? It is just not what was
called an original program in the past.
(If someone is too sensible to be called a clone programmer or derivative
programmer he just should start the harder way and not from a given 2700+
open source program. BTW I would like to see what he had 6 years ago - I bet there was nothing...)

Guenther

BTW it is very unpleasant that the current discussion is completely
away from the original topic! Since dozens of posts there is no talk
about N.S. aka Kranium, which is a very different case and I guess
the thread should be split.

The author of protector wrote the following words:

"Protector was written from scratch (about six years ago) as a bitboard-based program of its own. As a consequence it has a data structure that differs fundamentally from Toga's data structure. And of course Protector's algorithms refer to this data structure. For this reason it doesn't make sense to copy any *code* from Protector to Toga or vice versa."

I did not look at the code of protector but in case that he is right then
I think that protector is not a derivative of fruit or toga.

Uri

Denis P. Mendoza wrote:Check this out!

http://sourceforge.net/projects/protector/

I think this one will help initiate ideas here....for good! I'll be upset if nobody can try this on TDDB!

Protector is a Bitboard-based chess program that communicates with a chess GUI via the UCI protocol from Stefan Meyer-Kahlen.

In short it's kinda Bitboard-based TogaII with many small improvements. Take a look at the code for more details.

### SUPPORTED PLATFORMS

Currently Protector can be compiled and run on the following platforms:

- Windows XP 32-bit. Use Microsoft Visual Studio 2005. Protector should also run on Windows 2000 and Vista 32-bit but I haven't tested this.

- Windows Vista 64-bit. Use Microsoft Visual Studio 2005 with the 64-bit libraries. Protector should also run on XP 64-bit systems, but I haven't tested this.

- Ubuntu Linux 32-bit and 64-bit. Use ICC and the Makefile in the 'linux' folder. Install ICC 11.0, copy 'Makefile', 'depend' and 'tools.h' to the main folder and type 'make'. Protector should also run on other Linux distributions, but I haven't tested this.

Please note: For tests Protector should have access to at least 4-men Nalimov tablebases (better: 5-men), since it doesn't contain specialized code for primitive endgames.

### FUTURE WORK

It would be great if you support the further development of Protector in one of the following areas. I recommend to contact me via 'Raimund_Heid@yahoo.com' in advance.

- Speed optimization. I haven't speed-optimized Protector for a long time and I assume that it can be accelerated 10-20% by refactoring, an example being the usage of compiler intrinsics under Linux. Use the automated tests (assertions in debug mode) for refactoring.

- Evaluation. Of course this is an endless story. Protector currently is weak in estimating the value of rooks vs. knights and bishops in endgames. I assume that connected pawns need to be examined in order to assess this value more adequate. Another important weakness is 'king position in endgames' (distant passers, proximity to remaining pawn islands, king invasion).

- Parallel search. Currently Protector uses the shared hashtable approach for parallel search. The speedup with more than 2 processors is poor. Some more sophisticated SMP algorithm like YBW should do a much better job.

- Parallel search under Linux. Not much to be done. All that's needed is an exclusive access to the hashtable library since it doesn't seem to be thread-safe; see 'search.c'.

- GCC support. Not a big thing either, I suppose. ICC 11.0 (Intel C++ Compiler) compiles Protector without warnings. However GCC complains about the inline functions in the header files and wants to have them in the module files. I guess that a compiler switch can solve this, but I haven't found it yet.

- Mac support. I haven't compiled Protector on a Mac yet since I don't own one. I assume that it takes a couple of hours to get Protector compiling and running on a Mac, some support from you would be great!

### CREDITS

Protector is based on many great ideas from the following people: Fabien Letouzey (pvnodes, blending of opening and endgame values), Thomas Gaksch (pvnode extensions, extended futility pruning, space attack eval), Robert Hyatt (consistent hashtable entries), Eugene Nalimov (tablebases), Stefan Meyer-Kahlen (UCI), Gerd Isenberg (magic bitboards), Mike Donnig (testing), Vincent van Diepeveen (for reminding me to respect the value of someone else's work). Without their contributions Protector would not be what it is. Thank you so much.

Eelco de Groot wrote:[
I have not looked at any of the code from Protector but I suppose that although it may be correct that much of the datastructures in Protector may be different from Fruit or Toga, for the testing by CEGT or CCRL I think Protector l should still be regarded as belonging to the Fruit family. Just based on the authors further comments and also according to what Denis posted on TDDB in the first post on the subject, the comments from Raymund Heid himself in his read.me here:



Eelco

Eelco de Groot wrote:

Eelco de Groot wrote:[
I have not looked at any of the code from Protector but I suppose that although it may be correct that much of the datastructures in Protector may be different from Fruit or Toga, for the testing by CEGT or CCRL I think Protector l should still be regarded as belonging to the Fruit family. Just based on the authors further comments and also according to what Denis posted on TDDB in the first post on the subject, the comments from Raymund Heid himself in his read.me here:



Eelco

Well, on the other hand just looking though some of the files in the Protector download, now that I just opened some of the files, the source code is all very compact, more importantly I would not say I recognize anything as clearly being Fruit code or Glaurung code, so I well believe the author when he states he wrote his code from scratch, with influences and ideas from other people.

Protector has its own GPL license and does not need to fall under that of Fruit, unless it would share code that clearly comes from Fruit. So in that respect, maybe not such a good idea of mine to place it in the same group of engines with all the other Fruit varieties. (Many testers could indeed argue, there are maybe a little too many of those by now, too many to test them all )

I think the output from the engine and the games it plays will be recognizably different from that of the Fruit family, but that is just from looking at some of the code now, the testers will have to see for themselves!

Eelco