Author: Uri Blass
Date: 11:39:23 02/16/04
Go up one level in this thread
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
This page took 0.01 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.