Author: Komputer Korner
Date: 20:26:37 01/07/98
Go up one level in this thread
KOMPUTER KORNER ANNOTATION TABLE The following chart won't improve your chess but it will give you an idea of what exactly is meant by the annotation symbols that GM's use. Komputer Korner Annotation Table. Eval symbol % score for white % of a pawn ahead No. of tempos ahead ------------------------------------------------------------------------------------------------------------------------------ = or unclear/= 50 .00 0 +/=/= or unclear 56 .16 0.5 +/= 63 .33 1 +/- 76 .67 2 + - 90 1.0 3 +/-+/- >99 > 1.33 4 or more The difference between the = sign and the unclear/= sign in row 1 is that the unclear/= symbol represents a more dynamic position with much more winning chances for both sides. In row 2, the unclear symbol means the same thing as per the above with the exception that white has slightly more winning chances than black. Unfortunately, Sahovski Informator insists on using the =/unclear symbol for a material inequality position where there is sufficient compensation. Unfortunately that does not tell us whether there are lots of equal winning chances or if the logical outcome should be a draw. In practice, it has come to mean that the logical outcome is a draw which leaves a hole in the symbol annotations because there is no generally accepted symbol for the saying" both sides have equal chances". The unclear symbol can't be used for this because it does not represent an equality ( See Axiom No. 3 of Komputer Korner's 10 Commandments of Opening Theory). I propose that the =/unclear symbol be used in these cases. This then differentiates between a dynamic equality where both sides have equal chances to win, and the = symbol by itself which should mean that a draw is the likely outcome. The interpretation used by Sahovski Informator is thus misleading and not needed, because we already know that there is a materiel inequality just by looking at the position. The annotation symbols should restrict themselves to telling us who is better and if the position is equal, is it because both sides have lots of winning chances or is it because the position is a draw? -- KK On January 05, 1998 at 18:28:59, Don Dailey wrote: >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.