Author: Bruce Moreland
Date: 09:25:05 06/07/00
Go up one level in this thread
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. bruce
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.