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.