Author: Robert Hyatt
Date: 20:32:51 06/06/00
Go up one level in this thread
On June 06, 2000 at 18:13:33, Gareth McCaughan wrote: >On June 05, 2000 at 22:32:12, Albert Silver wrote: > >[I said:] >>> I don't understand this argument. You could say the same thing about >>> anything in the evaluation. Suppose the program has a choice between >>> two moves; one leads to this position, the other leads to some other >>> one-pawn-up position that *is* winnable. The other position evaluates, >>> let's say, at +0.9. Then it matters whether this one evaluates at >>> +0.4 or +1.0, no? >>> >> >> Sure, but not here. There is nothing obvious about stating that a rook ending >> with pawns on one wing and a one pawn advantage can't be won. There are >> far too many exceptions in my opinion for this to work, so that this >> knowledge is useless (as it is incomplete), and dangerous (as it may >> lead to incorrect decisions). In order to validate this knowledge, I am >> of the opinion that one would have to include far too many conditions >> for it to justify the slowdown it would inevitably cause. > >It's not necessary to "validate this knowledge". Everything in the >eval (more or less) is heuristic. > >Let's consider two chess programs. One of them has a rule that says >something like "If the only pieces on the board are kings, rooks and >pawns, one player has one pawn more than the other, and EITHER all >of each player's pawns are connected on the K-side, OR all of each >player's pawns are connected on the Q-side, and the player with >one pawn more is deemed to be ahead by an amount x, then decrease >the eval by x/2 or 0.5, whichever is smaller". The other doesn't. > >To save effort, I'm going to use the term "one-sided R+P position" >to mean a R+P position that specifies the conditions in the rule. > >Now, there are three ways in which the programs could be of different >strengths. > >1. The "clever" program has a slightly slower evaluation function. > It might be very slightly weaker as a result. > >2. The "clever" program will evaluate some positions better, namely > one-sided R+P positions which are unwinnable or much harder to > win than they would be if they weren't one-sided. > >3. The "clever" program will evaluate some positions worse, namely > one-sided R+P positions which are winnable about as easily as > they would be if they weren't one-sided. > >The "clever" program will be better if 2 outweighs 1 and 3. If, say, >75% of one-sided R+P positions are significantly more drawish than >they would be if they weren't one-sided, and if the slow-down from >having the rule is extremely small (both of which seem plausible to >me, though I'm open to correction from better chess players or people >who know more about writing computer chess programs), then the "clever" >program will be better. > >I don't see how this is "useless" and "dangerous". Unless what you're >saying is that actually most one-sided R+P positions aren't made >any more drawish by being one-sided (and that no adjustment to the >rule described above would change that), but that doesn't seem plausible >to me. > >-- >g What would be dangerous is to say "in a R+P ending, if _all_ pawns are on one side of the board, divide the eval by 2, making it more drawish." The danger is that the program is a _full-width_ searcher. It will search so many different positions that it will guarantee itself to search positions where that bit of advice is wrong. Yet it will rely on it to "save itself" from losing a game that it will suddenly think is kind of drawish. The think to keep in mind is how fast these thing are searching. On my quad xeon, I see 1M nodes per second. That is a _bunch_ of positions. If only .01% of the positions is mis-evaluated, that is still a big number when you factor in the search speed. The idea here is that the eval terms you use really do have to be accurate nearly 100% of the time. Otherwise the program will force those inaccurate cases to happen and then use them to skew the eval and fool itself about what is going on. It is a very dangerous tightrope to walk... I can't count the number of times I have written code that works almost all the time... and then am amazed to see how many times the silly search can make those exceptions occur, when they will do the most damage.
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.