Author: Robert Hyatt
Date: 11:52:06 07/25/00
Go up one level in this thread
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 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... > >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.. > >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. 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. :)
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.