Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: definition of clones: Danchess an Crafty

Author: Uri Blass

Date: 10:53:12 02/16/04

Go up one level in this thread


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



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.