Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: definition of clones: Danchess an Crafty

Author: Uri Blass

Date: 01:08:23 02/16/04

Go up one level in this thread


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

I can add that I may decide not to use the SEE that I have at the last ply of
the qsearch for different reasons.

I today use the SEE only in the last ply of the qsearch.

I care about worst case and I never want my qsearch to explode even in leonid's
positions but it may be better to have a special qsearch function that looks
only at one capture per side after some plies of qsearch to prevent qsearch
explosion so I practically do not need my see that is not accurate to prevent
qsearch explosion(in the past I even did not have SEE in the last ply of the
qsearch and simply assumed that the side to move can earn a pawn and returned
evaluation and using SEE did not make a big difference).

usually qsearch is less than 7 plies so the difference is clearly very small for
different decisions.

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.