Author: Robert Hyatt
Date: 11:24:18 02/16/04
Go up one level in this thread
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...
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.