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