Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: definition of clones: Danchess an Crafty

Author: Uri Blass

Date: 12:41:49 02/16/04

Go up one level in this thread


On February 16, 2004 at 15:40:24, Robert Hyatt wrote:

>On February 16, 2004 at 15:26:10, Uri Blass wrote:
>
>>On February 16, 2004 at 14:57:34, Robert Hyatt wrote:
>>
>>>On February 16, 2004 at 14:39:23, Uri Blass wrote:
>>>
>>>>On February 16, 2004 at 14:24:18, Robert Hyatt wrote:
>>>>
>>>>>On February 16, 2004 at 13:53:12, Uri Blass wrote:
>>>>>
>>>>>>On February 16, 2004 at 13:38:50, Robert Hyatt wrote:
>>>>>>
>>>>>>>On February 16, 2004 at 13:22:56, Uri Blass wrote:
>>>>>>>
>>>>>>>>On February 16, 2004 at 10:02:10, Robert Hyatt wrote:
>>>>>>>>
>>>>>>>>>On February 16, 2004 at 03:48:08, Uri Blass wrote:
>>>>>>>>>
>>>>>>>>>>On February 15, 2004 at 16:44:33, Robert Hyatt wrote:
>>>>>>>>>>
>>>>>>>>>>>On February 15, 2004 at 15:53:16, Uri Blass wrote:
>>>>>>>>>>>
>>>>>>>>>>>>On February 15, 2004 at 14:48:29, Robert Hyatt wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>On February 15, 2004 at 14:43:06, Bob Durrett wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>On February 15, 2004 at 14:29:52, Robert Hyatt wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>><snip>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>In view of the size and complexity of Crafty I wonder whether or not cloning
>>>>>>>>>>>>>>Crafty is really a good idea for the newbie chess programmer to get started.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>On the other hand, maybe there are parts of crafty which could be used in the
>>>>>>>>>>>>>>beginning so that the newbie programmer could concentrate on creating his/her
>>>>>>>>>>>>>>own code for the really important parts.
>>>>>>>>>>>>>
>>>>>>>>>>>>>I don't disagree.  The parts that always cause me the most concern center around
>>>>>>>>>>>>>the evaluation and search.  I didn't look at his search carefully at all, but I
>>>>>>>>>>>>>did look at the evaluation, and that has too much copied code...  There may be
>>>>>>>>>>>>>significant search code copied or not.  But copying either is really copying the
>>>>>>>>>>>>>"personality" of the program...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>I think that by that logic a lot of programs copied the "personality" of Crafty
>>>>>>>>>>>>even if they do not use bitboards.
>>>>>>>>>>>>
>>>>>>>>>>>>Your words imply that it is better if I continue not to evaluate correctly KRP
>>>>>>>>>>>>vs KR endgames because if I evaluate them correctly then I copy the personality
>>>>>>>>>>>>of Crafty that also knows to evaluate them correctly.
>>>>>>>>>>>
>>>>>>>>>>>No, I didn't say that.  I didn't imply that.  I didn't suggest that.  That is
>>>>>>>>>>>your imagination.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>You did not say it but the words "copying the personality of the program"
>>>>>>>>>>gave me that impression.
>>>>>>>>>
>>>>>>>>>If you re-read what I wrote, ".. copying search code or evaluation code is
>>>>>>>>>really copying the personality ..."  (paraphrased).  I am _still_ talking about
>>>>>>>>>specifically copying source code, nothing else...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>The question is how do you define the personality of the program.
>>>>>>>>>>I think that the personality of the program is expressed by the algorithms
>>>>>>>>>>that it is using.
>>>>>>>>>>
>>>>>>>>>>When I read again your post I understand better your opinion when I see that
>>>>>>>>>>Danchess use bitboard in the same way as Crafty(Movei is not bitboard based and
>>>>>>>>>>the bitboards that I use use mainly for pawn structure are defined different
>>>>>>>>>>than Crafty).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Here is what I said:
>>>>>>>>>>>
>>>>>>>>>>>"copying _ideas_ is perfectly OK.  Copying _source code_ is _not_ perfectly OK."
>>>>>>>>>>>
>>>>>>>>>>>I didn't say any more or less than that.  I am talking about copying source
>>>>>>>>>>>code.  I would not be terribly concerned by someone copying my move generator,
>>>>>>>>>>>in fact, since that produces deterministic output, and ten different people
>>>>>>>>>>>could write 10 different move generators, but they had better produce the _same_
>>>>>>>>>>>set of moves.
>>>>>>>>>>
>>>>>>>>>>The ouput is not deterministic because the order of moves may be different.
>>>>>>>>>
>>>>>>>>>Notice I said the "same set of moves".  That is definitely deterministic.  Order
>>>>>>>>>is another issue, but even then copying my move order is not a problem.  There
>>>>>>>>>have been database engines that depend on move order as they just store a move
>>>>>>>>>as a single byte, in index into the stream of legal moves.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  But if you copy the bitboards, and then you copy the static
>>>>>>>>>>>exchange evaluator, and then the positional evaluation, and then ...  Then you
>>>>>>>>>>>have simply gone too far.
>>>>>>>>>>
>>>>>>>>>>I understand.
>>>>>>>>>>I think that the static exchange evaluator is not the main point here because
>>>>>>>>>>static exchange evaluator is something that is leading to almost deterministic
>>>>>>>>>>output(I do not say deterministic because my SEE stops after the first king
>>>>>>>>>>capture that is different than Crafty's SEE and I also stop SEE in case that the
>>>>>>>>>>result is obvious based on previous captures like Bxp QxB RxQ when it is obvious
>>>>>>>>>>that the side with the bishop won a pawn).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Correct.  I only used swap.c as an example because it is small enough for anyone
>>>>>>>>>to look at and compare with mine.  evaluate.c is much harder because it is much
>>>>>>>>>larger.  But the same idea holds...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>If I understand correctly the similiarity in the code inside Swap is not the
>>>>>>>>>>main problem and the problem is also that it is using bitboards that are
>>>>>>>>>>identical to crafty.
>>>>>>>>>
>>>>>>>>>The bitboards are not really the problem.  All the duplicated code is what is at
>>>>>>>>>issue.  IE lots of arrays same size, same content (sometimes slightly different
>>>>>>>>>names).  Eval code that is duplicated in many places...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>I guess that a code that use similiar swaplist to crafty, but use different
>>>>>>>>>>bitboards and different functions for AttacksTo and SwapXrays than crafty and
>>>>>>>>>>use special functions to find firstknight,firstbishop,... based on piece list
>>>>>>>>>>and bitboard of attacks, will not produce the same problem.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>No, again you are taking this too literally.  swap.c is simply _one_ example of
>>>>>>>>>a much more pervasive problem in danchess...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>This is the case in the code of my latest non public version of movei and I
>>>>>>>>>>almost do not use that SEE function because based on my tests I did not find it
>>>>>>>>>>to be productive even to prune bad captures because I have already different
>>>>>>>>>>code to prune part of the bad captures and today I use it only to evaluate leaf
>>>>>>>>>>nodes when the qsearch is too long(more than 7 plies).
>>>>>>>>>>
>>>>>>>>>>Note that in my case my SEE is more accurate than Crafty because I do not
>>>>>>>>>>consider captures after capturing king so trading kings cannot happen.
>>>>>>>>>>
>>>>>>>>>>I can leave this code out of movei without big change in playing strength if you
>>>>>>>>>>do not like it.
>>>>>>>>>
>>>>>>>>>Uri, please read carefully:  I don't object to _anyone_ copying any _idea_ from
>>>>>>>>>Crafty.  Otherwise I would not have published the source in public.  I don't
>>>>>>>>>even care if someone copies a piece here and there for some of the things in
>>>>>>>>>Crafty.  Just not nearly complete copies of the evaluation, etc...  I can give
>>>>>>>>>examples if you want.  IE, who does the "EvaluateDevelopment()" stuff I do about
>>>>>>>>>castling on both wings?  danchess does.  Who has "EvaluatePassedPawnRaces"
>>>>>>>>>stuff?  same answer.  Etc...
>>>>>>>>
>>>>>>>>I understand.
>>>>>>>>
>>>>>>>>Correct me if I am wrong but my guess based on the descreption is that the main
>>>>>>>>problem is that the author started by copying most of the data structure of
>>>>>>>>crafty(maybe with different names).
>>>>>>>
>>>>>>>No crystal ball here, so I have no idea where he started.  I've never seen the
>>>>>>>program play, I've never seen games it has played.  I have no idea how long it
>>>>>>>has been around or anything else....
>>>>>>
>>>>>>You cannot know where he started and it is possible only to guess but you can
>>>>>>know if most of the data structure is taken from crafty.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>His first program was clearly weaker without knowledge about king safety and
>>>>>>>>even the latest version is weaker than Crafty so I do not think that he started
>>>>>>>>from Crafty and modified it but it is wrong to start from that basis because
>>>>>>>>later if you want to learn from crafty about improving your evaluation it is
>>>>>>>>natural to add code similiar to crafty even if you do not do copy and paste and
>>>>>>>>understand the ideas.
>>>>>>>
>>>>>>>I didn't see his "first program".  His current program clearly knows as much
>>>>>>>about king safety as mine.
>>>>>>
>>>>>>He said that one of the things that he added to his first program is knowledge
>>>>>>about king safety so I am not surprised to read it.
>>>>>>
>>>>>>
>>>>>>  It computes the "king tropism" exactly the same way,
>>>>>>>using the same numbers I use.  It then runs them thru an exponential mixer to
>>>>>>>make three close pieces way better than two close pieces.  Same array mixer,
>>>>>>>same mixing values.  Etc.  So I can't comment on why his king safety would be
>>>>>>>worse since what I have here (both his source and executable) seems to be
>>>>>>>identical in regard to king safety...
>>>>>>
>>>>>>Note that I did not see his code to give comments except the small code that
>>>>>>Dann posted in the winboard forum.
>>>>>>
>>>>>>Uri
>>>>>
>>>>>
>>>>>Here is a sample of the king safety stuff:
>>>>>
>>>>>DanChess:
>>>>>
>>>>>const char     BOARD::king_tropism_n[8]         = {3,3,3,2,1,0,0,0};
>>>>>const char     BOARD::king_tropism_b[8]         = {3,3,3,2,1,0,0,0};
>>>>>const char     BOARD::king_tropism_r[8]         = {3,3,3,2,1,0,0,0};
>>>>>const char     BOARD::king_tropism_at_r[8]      = {4,3,1,0,0,0,0,0};
>>>>>const char     BOARD::king_tropism_q[8]         = {4,4,4,2,1,0,0,0};
>>>>>const char     BOARD::king_tropism_at_q[8]      = {5,5,3,0,0,0,0,0};
>>>>>
>>>>>const char BOARD::weight_tropism[]=
>>>>>{
>>>>>         16,16,16,16,17,17,18,18,
>>>>>         19,19,20,20,21,21,22,22,
>>>>>         23,23,24,24,25,25,26,26,
>>>>>         27,27,28,28,29,29,30,30,
>>>>>         31,31,32,32,32,32,32,32,
>>>>>         32,32,32,32,32,32,32,32,
>>>>>         32,32,32,32,32,32,32,32,
>>>>>         32,32,32,32,32,32,32,32
>>>>>};
>>>>>
>>>>>
>>>>>
>>>>>Crafty:
>>>>>
>>>>>const char king_tropism_n[8] = { 3, 3, 3, 2, 1, 0, 0, 0 };
>>>>>const char king_tropism_b[8] = { 3, 3, 3, 2, 1, 0, 0, 0 };
>>>>>const char king_tropism_r[8] = { 3, 3, 3, 2, 1, 0, 0, 0 };
>>>>>const char king_tropism_at_r[8] = { 4, 3, 1, 0, 0, 0, 0, 0 };
>>>>>const char king_tropism_q[8] = { 4, 4, 4, 2, 1, 0, 0, 0 };
>>>>>const char king_tropism_at_q[8] = { 5, 5, 3, 0, 0, 0, 0, 0 };
>>>>>
>>>>>const char ttemper[64] = {
>>>>>  16, 16, 16, 16, 17, 17, 18, 18,       /*   0-   7 */
>>>>>  19, 19, 20, 20, 21, 21, 22, 22,       /*   8-  15 */
>>>>>  23, 23, 24, 24, 25, 25, 26, 26,       /*  16-  23 */
>>>>>  27, 27, 28, 28, 29, 29, 30, 30,       /*  24-  31 */
>>>>>  31, 31, 32, 32, 32, 32, 32, 32,       /*  32-  39 */
>>>>>  32, 32, 32, 32, 32, 32, 32, 32,       /*  40-  47 */
>>>>>  32, 32, 32, 32, 32, 32, 32, 32,       /*  48-  55 */
>>>>>  32, 32, 32, 32, 32, 32, 32, 32        /*  56-  63 */
>>>>>
>>>>>What would you conclude???
>>>>>
>>>>>There is more if you want to see it.  _much_ more...
>>>>
>>>>Thanks.
>>>>
>>>>having exactly the same numbers as crafty is copying and I see no reason to do
>>>>it.
>>>>
>>>>I understand that the numbers are used for evaluation.
>>>>I do not know exactly how they are used but it is not clear if the numbers in
>>>>crafty are the optimal numbers and I do not see a reason to use exactly the same
>>>>numbers.
>>>>
>>>>I think that this example is more convincing then the example of the code of
>>>>SEE.
>>>>
>>>>Uri
>>>
>>>
>>>I used the SEE example because swap.cpp and swap.c are short.  To find the
>>>above, you have to dig through evaluate.c and board_evaluate.cpp, which add up
>>>to several thousand lines of code, total.
>>>
>>>As I said, I didn't reach this conclusion casually.  When you see such numbers
>>>copied "as is" then something is up, because I hardly think that I am some sort
>>>of genius that came up with the "perfect" set of values as given above.
>>
>>
>>Note only this but even if we assume that you are genius then it is not clear if
>>the same numbers that are best for crafty are also best for another program.
>>
>>Uri
>
>
>I wouldn't disagree.  However I am pretty certain my numbers are _not_ the best,
>even for Crafty.  I just haven't found any better.  Not that they don't exist...

I am pretty certain it is the same for all programmers.

Uri



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.