Author: blass uri
Date: 10:56:54 10/14/99
Go up one level in this thread
On October 14, 1999 at 10:10:51, Robert Hyatt wrote: >On October 14, 1999 at 03:56:14, Ratko V Tomic wrote: > >>>> Thus the micro chess programmers have to think much harder to produce >>>> the highest quality evaluation functions, while DB programmers can stuff >>>> almost anything that comes to mind, >>> >>>Exactly. They can stuff 'anything that comes to mind' in their evaluation, >>>because it'll still be the same speed. So why would they use a simple >>>evaluation, when they can use a function of arbitrary complexity at the same >>>speed? >> >>More stuff in the evaluation won't necessarily improve choice. Lots of such >>advice, like the folk wisdom, comes in pairs of opposite polarity (is it better >>to be the "early bird" or make waste from haste etc). A well thought out and >>finely tuned (to the context) function should do better than a mass of stuff not >>as well tuned. A creative spark needed for this kind of black magic, as it were, >>prefers those who are under greater contradictory constraints. >> >>> >>>You have: >>> >>>A) A chess program, written by one of the best chess programmers there is, >>>running on an ordinary desktop computer (Perhaps even a 700 MHZ Athlon). >>> >>>or B) A chess program, written by more than one of the best chess programmers >>>there are, running on a supercomputer with hundreds of special-purpose >>>chess-chips to evaluate in hardware what would take 100x longer on a >>>general-purpose CPU. Also note that use of several GMs was employed to help >>>tune and improve the evaluation. >>> >>> >> >>Otherwise same person, but in a harder situation will be more creative, so >>they'll get more performance per unit of crunching power, no question about it. >>As to the GM advice, well, it may be useful to the programmers in matters that >>are of algorihmic nature (mostly the endgame techniques) or in tuning the >>opening books (provided they have a good sense what fits the program otherwise). > >That is simply _totally_ wrong. Using micros, we decide what we want to eval, >we try it, and decide whether the gain from the knowledge is worth the cost in >search speed/depth. Hsu does the same, except rather than having to choose >whether to use it or not due to speed, he decides whether to use it or not based >on whether he wants to design the hardware to handle that. > >_EXACTLY_ the same issue, just in a slightly different context. If you really >believe that others are more creative than the DB team, you are _sadly_ >mistaken. > > >>The other advice, of more strategic kind, it's not clear whether that kind of >>knowledge will help or harm the program. Some principle which may loom important >>to a GM (and maybe it is within his algorithm, much of which is subconscious, >>though) may be expensive to compute and within program's algorithm it may be of >>very little or no use, or even it may cause harm (e.g. ideas on indirect control >>of center or of an isolated central pawn, which GM may like to have). >> >>It's like with "expert systems," it sounds better than it works. >> > >In this case, it seems to have worked incredibly well, wouldn't you say? >No other machine around can beat Kasparov in a match. No other machine can >even beat a strong human given the position reached in game 6. Yet DB made >it look easy. I believe that kasparov is the one who made it look easy by playing some bad moves in a line that he was not prepared to play. Uri
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.