Author: Don Dailey
Date: 15:28:59 01/05/98
Go up one level in this thread
On January 05, 1998 at 08:12:47, Simon Read wrote: >On January 04, 1998 at 20:45:00, Robert Hyatt wrote: > >>The moral? The pawn hole code definitely improved CB at shallow depths. >> But >>CB understood outposts and weak pawns and so forth, and going from 4-5 >>plies >>to 9-10 plies made that pawn-hold code simply a "double penalty" because >>it >>got a penalty for the hole, plus it got a penalty when it saw how to >>utilize >>that hole. > >Superficially, one would think a good position is a good position >is a good position. However, it's only good if the subsequent search >can take advantage of it. > >If I understand this correctly, your evaluation function can steer >the program towards a position, thinking it's a good position. If >the program searches (e.g.) 10 ply beyond that position (when it >reaches it, of course) it can take advantage of it and win. If the >search is only (e.g.) 5 ply, the search will in fact blow it completely >and lose. So evaluation functions with shallow searchers should >avoid delicate double-edged positions. > >This means that a search which is "safe" for a shallow searcher will >actually hamper a deep searcher by having too great a margin of >safety on some sorts of positions. Hi Simon, Very nice. This is something that makes sense and at least attempts to apply some methodology and order to this phenomenon. I once decided that an evaluation assigned to a position does not accurately measure how good a position is. If it did we would only see checkmate scores and draws because a position is always won, lost or drawn. But when we apply scores to positions we are really estimating the computers chances of winning the game. A score of 1.5+ might mean 90% chance of winning, etc. A score of exactly 0.0 means 50% chance of winning (or a forced draw which can be considered 50% of a win and is the same.) Most programs will evaluate the opening as someone positive which indicates a better chance of winning. But I happen to know my program does not handle rooks well. Instead of trying to figure out the "true" value of a rook, we should be considering the rooks value as a function of how it affects our winning chances. In this case it should be at least a little less than what we consider it "true" value simply because we don't believe as much in it's ability to improve our chances. Once I also "noticed" that queen mobility seemed to hurt the programs play because it tended to bring the queen out too early. But the problem seemed to go away with depth. I just figured this was because with depth we simply play better. But your explanation makes some sense in this example. The general principle of queen mobility is a correct one, but it takes skill to apply it correctly and need some depth. So perhaps the bottom line is to steer for positions you have the required technique to handle well. Here is another example. Years ago we had a little test that looked to see if a knight was trapped on a8 or h8. If it was, we assigned a penalty of about 1.5 pawns I think. The algorithm helped a lot because our program never looked deep enough to see the consequences. But a few years later (after dropping the algorithm) I noticed that we would take something on a8 and more often than not get away with it. So in the context of your explanation I can see how it might be quite prudent to "avoid" a situation we are guaranteed not to evaluate well but embrace it when we have more confidence in our skill. > >My other comment on searching is the "side-effect" feature. >Let's suppose that your evaluation function counts pawns >AND NOTHING ELSE. As your search depth goes up, your program >will discover that the way to keep its pawns is to preserve >material, so that it's able to defend its pawns. Yet deeper >searches will cause it to maintain a good control of the >board generally to prevent the opponent getting into position >to attack its pawns. >Ultimately, of course, this sort of program will still crack up >spectacularly, finding a deeeeeeeeeep combination which sacrifices >all material in order to win all its opponent's pawns. However, >in the meantime, it will (completely by accident) have synthesised >a side-effect, discovering things like material and position. > > >The above would make it very difficult to pin down exactly why a >program behaves the way it does: it may appear to have a very >good idea of positional control but only as a complicated side- >effect of some other term in the evaluation function. > >Simon Yes, this is a well known phenomenon. There are times when Cilkchess seems to actually understand positional chess when in fact it doesn't have a clue! -- Don
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.