Author: Graham Laight
Date: 03:54:12 07/26/00
Go up one level in this thread
On July 25, 2000 at 14:52:06, Robert Hyatt wrote: >On July 25, 2000 at 12:12:21, Graham Laight wrote: > >>On July 25, 2000 at 09:43:44, Robert Hyatt wrote: >> >>>On July 25, 2000 at 06:48:09, Graham Laight wrote: >>> >>><snip> >>> >>> >>>> >>>>It seems to me that you are selecting which knowledge to use on the basis of >>>>"inductive reasoning", or a tree of questions. >>>> >>>>e.g. >>>> >>>>Is there plenty of material left? >>>> | >>>> | >>>> |- Yes >>>> | | >>>> | |- Are the opponent's pieces near my king? >>>> | | >>>> | |- Yes >>>> | | | >>>> | | |- Are the pawns around my king well placed? >>>> | | | >>>> | | |- No >>>> | | | | >>>> | | | |- A king safety problem exists >>>> | | | >>>> | | | >>>> |---|---| >>>> | >>>> | >>>>A king safety problem does not exist >>> >>>You imply this is a boolean decision. It isn't. The king safety scores can >>>range over a set of integer scores from roughly -5.00 (-500 in Crafty) to +5.00, >>>rather than being a decision tree 0/1 as you have it above. That seems to help >>>my evaluations quite a bit, because over time, the endgame prediction score can >>>catch up and surpass the king safety score causing crafty to want to trade >>>even when it is attacking, because it has seen (or thinks it has seen) a way >>>to reach an endgame where it has an advantage that is better than the attacking >>>chances. >>> >>>That is important in my evaluation... there are no "on/off" things at all. IE >>>some turn king safety off when material drops below X. Right around X, things >>>are flakey as on one side you get a big negative score, while on the other side >>>you get a 0, so a single capture can whack the score significantly. I don't >>>do that... it smoothly transitions from big to small over many captures... And >>>endgame scores smoothly transition from small to big as material comes off. >>> >>>What it means is that I evaluate everything, then figure out how much of each >>>"component" ought to be included in the current score, rather than turning some >> >>How do you weight the various components? > >I assume you mean how do I determine the numbers to use? If so, I make a This is not really what I meant, but I'm glad I was misinterpreted, because what you said was quite interesting! What I meant was, what is the _mechanism_ you use to determine the relative weighting between eval components? Here is how I think you do it: 1. you calculate some "indices" for the position (e.g. amount of material) 2. you calculate your values for king safety and endgame "winnability" 3. you weight the above values according to the indices calculated in step 1 If this is correct, then it is similar to what I'm proposing to do, except that I'm (roughly speaking) proposing to do it systematically for all eval components! >SWAG, and then run it on ICC and watch as games are played. It will become >obvious if the numbers are not reasonable, and with enough games they become >tweaked into the right range... > >As far as endgame vs king safety, the evaluation is actually pretty good >here, but it has evolved over a long time (the comments in main.c can tall >you how many times king safety was completely rewritten from the ground up >to make it work better...) > >The only minor headache is that everything is an "average". And sometimes >it might break off an attack to go for an endgame it thinks it is winning, >but due to some odd exception, it isn't. Or in other times it might continue >an attack when it could break off and go into an ending where it will win >easily but doesn't quite think so. When you average, you accept some errors >of course... And then you try to special-case those errors out as well... As previously stated, I'm starting with the idea that chess is full of "exceptions", or types of position that require special knowledge, and I want to manage the knowledge about them methodically! >> >>I assume you have to calculate (or use existing calculations to make..) some >>indices to determine the relative weight the score of each evaluation component >>should be given. If so, this sounds similar to the position index building work >>I would have to do before giving each eval fn a "match score". >> >>>off completely. IE if your king is in trouble, you might turn pawn structure >>>analysis off as you are trying to save your king. I am trying to save both >>>my king _and_ pawn structure, but I try harder to save the king of course. :) >> >>I would be able to set the match score threshold for using an eval fn to >>whatever I liked. >> >>It could be "top 5 + anything with a match score over 50%", or it could be "top >>10 + anything with a match score over 10%". I could even choose to use all eval >>fns, and use the match scores to determine weightings. >> >>One could have hours of fun playing with the thresholds... :) >> >>Anyway, to go back to Crafty for a moment, the thing that struck me when looking >>through evaluate.c (17.11) is just how little knowledge there is in there. I've >>just done a quick count (unscientific I know), and I reckon there's fewer than >>150 distinct pieces of chess knowledge in that file! > > >You have to look very carefully. While it seems to be computing one piece of >knowledge, it is also (often) setting things that are going to be used in other >places (second/third order effects). IE the tropism stuff doesn't compute a >score, just a "how many pieces and how close are they to my king" value, that >is then combined with other terms in a complex expression. > >IE many values are 'independent' things. Others interact with different pieces >of the eval in complex ways... > >And just because there is one "term" or "number" you might notice in many cases >that there are multiple pieces of 'knowledge' folded together to activate that >particular term.. I agree that lots of knowledge is accounted for in this way in evaluate.c. However, in most cases, you've done an extremely good job of commenting what you are doing. I commend your programming highly - evaluate.c (17.11) is a beautiful piece of code to read! The way I did my (quick, dirty, and unscientific) count of the rules you have used was via these comments. Where the comments showed more than 1 rule, I have counted them as such (e.g. from your development eval: "(1) don't move the queen until minor pieces are developed; (2) advance the center pawns as soon as possible; (3) don't move the king unless its a castling move" is counted as 3 rules). Thus, even if the < 150 number is wrong (if you want to be pedantic, you could argue about stuff like whether counting certain things separately for both sides counts as different rules), it's probably in the right order of magnitude. Again, this is not intended to be criticism - it's just my observation. > > >> >>This is an eminently manageable number, so it's not surprising that knowledge >>management issues are not seen as a serious problem in Crafty. Indeed, it is a >>tribute to the programmer that Crafty plays so well with so little knowledge >>about chess. >> >>I think we can safely say that Crafty's depth of search eliminates the need for >>large chunks of knowledge. Bad positional aspects which are hard to see must >>eventually lead to bad things in the position which can easily be seen - and >>evidently Crafty sees far enough ahead to catch most of these. > > >I disagree about the depth issue. Crafty's search is not great by any measure. >It is just "ok". And against GM players, that intentionally play into positions >where tactics don't happen, search isn't enough. That is why crafty (probably >hidden to your quick look) detects the number of blocked pawns, the number of >potential pawn levers, etc, in an effort to avoid or eliminate blocked >positions, or to at least maintain the option of unblocking if need-be. These "rules" are all commented, so I have counted them (see above). >I think a program that relies only on depth will get into great difficulty >against GM players. If I have done any one thing over the past 3 years, it >has been working to combat this anti-computer stuff. It's a long way from >perfect, but it doesn't get things blocked up very often... > >> >>Still - having such a relatively small number of rules must leave positional >>holes that players could exploit if there was a lot at stake (e.g. a big >>competition). >> >>-g > > >I don't see "big" holes. I had a chat with two GMs this week, in fact, and >neither came up with any serious flaws they thought needed immediate attention, >this for the first time in a couple of years that this has happened. This is >not saying there are no holes... just no "gaping holes" that they noticed... > >Which is a good sign, as they had been reporting 'gaping holes' regularly until >the last couple of months... Now we start on the 'sorta-gaping holes' I guess. > >:) I will follow the process with interest, as long as you keep reporting it! -g
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.