Author: Graham Laight
Date: 04:55:15 06/09/00
Go up one level in this thread
On June 08, 2000 at 20:28:10, Bruce Moreland wrote: >On June 07, 2000 at 13:10:23, Graham Laight wrote: > >>On June 07, 2000 at 12:25:05, Bruce Moreland wrote: >> >>>On June 07, 2000 at 05:55:23, Graham Laight wrote: >>> >>>>On June 06, 2000 at 23:51:54, Bruce Moreland wrote: >>>> >>>>>On June 06, 2000 at 23:32:51, Robert Hyatt wrote: >>>>> >>>>>>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. >>>>> >>>>>It's not true that any error in the tree is inevitably fatal. And it's not true >>>>>that it's wrong to add knowledge if the knowledge can be wrong. >>>>> >>>>>You already have anti-knowledge by not having the term. There's no reason to >>>>>assume that this is any better than knowledge. >>>>> >>>>>What you want in these cases is to reflect tendencies, not to just say "return >>>>>0". I think it's possible to do this safely. >>>>> >>>>>bruce >>>> >>>>Like I've always said, there are two possible approaches: >>>> >>>>1. Get such a fast computer that sufficient search depth can be done to >>>>eliminate all knowledge problems >>>> >>>>2. Organise the knowledge methodically so that it is used only in positions >>>>where it is likely to be relevant >>>> >>>>I've discussed some different approaches to doing no. 2 in the past. >>>> >>>>I agree it's one of those things that's easier to say than to do - and I'm happy >>>>to settle for being a critic for now! >>>> >>>>-g >>> >>>If you take steel and concrete you get something that is much stronger than >>>either alone, as evidenced by the half-ton chunk of the stuff in my back yard, >>>which I am going to have to rent a jack hammer to get rid of, and even that >>>might not work. I may have to just repeatedly dig out under the thing until it >>>is far enough underground that I can just bury it. The previous owner of this >>>house was apparently *very* concerned that his clothes line post not fall over. >>> >>>My point is that a common problem when people are writing a "conventional" >>>program is too much concern about precision. You can combine search with eval >>>and precision will grow out of that, even though the eval isn't that precise. >>> >>>What you want to avoid with eval is cases where search can't improve the eval. >> >>Sorry, but I'm not sure what you mean by this. >> >>I would guess you mean either: >> >>* you believe so deeply in the eval that you don't do any more searching, when >>actually you should >> >>or >> >>* Doing extra searching from this node would be pointless because the "truth" in >>the position is too far ahead to be able to get to by asking for extra searches >> >>If you can spare a minute, could you clarify your last sentence, please? > >In some of the positions discussed in this thread, the truth isn't that far >away. If someone has a king on h7 and a pawn on g6, it is going to queen in >three moves, and if you're searching a K+P ending you are going to figure this >out unless you encounter it at a near-tip node. > >In some of the positions, a few simple terms suffice, even if you encounter the >position at a tip node. In the aforementioned case, you probably have a bonus >for an advanced pawn, if not an advanced passed pawn, if not an advanced passed >pawn with the king in proximity and ahead of it, if not a pawn that can be >escored all the way to the queening square. All of these terms are pretty easy. > I especially like the king suppor term. > >In some of the positions, eval won't help, and the truth is too deep for search. > >I think that in most of the cases discussed in this thread, a combination of >decent search and a few obvious eval terms are good enough. In the cases that >are harder than this, the positions are probably somewhat too esoteric to make >it work it to add extra eval, although perhaps I am wrong. > >I don't think it's important to deal with the case where you have kings on the >k-side, and you have to run them both to the Q-side to interact in some way with >a pair of pawns. This case can be dealt with with 4-man tables. > >A case that is harder is when there's a drawn situation q-side, but the stronger >side has an extra pawn k-side. If the k-side pawn was gone it could be dealt >with easily, and if the two q-side pawns were gone the single k-side pawn could >be understood easily. But the combination is harder. The stronger side is apt >to return a positive score even though it's diddling around with its pawn, >simply defending it. It's the same sort of thing you get if you have KP vs K >and no special endgame knowledge or talbes. The stronger side can keep its pawn >and avoid repeating position for quite a while, so you get a bogus value. > >Which is getting to be somewhat afield of what I was responding to. I think I >was responding to the question of whether to solve problems with eval or with >search, by suggesting that both in combination may work better. > >Some people who do chess programs seem to want to optimize for depth, and others >want to make the world's best eval. My goal is to make the best eval I can, as >long as it's fast and doesn't seriously hinder depth. > >bruce Ah - now I understand! Thanks for taking the time to clarify that. You earlier said that concrete + steel together are stronger than either one alone. However, it may be that steel alone is actually stronger than concrete and steel combined. In this instance, steel represents knowledge, and concrete represents search. For computer programmers, concrete seems to be available in abundance, but steel is in relatively short supply. For humans, it's the other way around. A human relies, compared to computers, almost 100% on knowledge - yet some of them can still beat the silicon players. They do this by: 1. Evaluating the positions they see very well, and 2. Pruning their search. Good players don't look at many moves in most positions. The humans run into trouble mainly because they have removed from their search a line which they should have examined, but which they actually pruned out in the interests of time. What the programmers have not yet succeeded is in doing is what ultimately has to be done if computers are to become clearly better than the top humans without having to wait for Moore's Law to deliver sufficient search speed: address the issue of managing a large amount of knowledge sufficiently well (and in an easily maintainable way!) so that when a node is being evaluated, or a decision is being made about whether to extend the search at this node, the most relevant knowledge for this type of position can be quickly made available. -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.