Author: Graham Laight
Date: 15:36:28 07/19/00
Go up one level in this thread
On July 19, 2000 at 15:02:14, Amir Ban wrote: >On July 19, 2000 at 11:06:13, Alvaro Polo wrote: >>I'll believe that adding new knowledge to Junior is almost free. I have then two >>questions. >> >>1.- Why isn't then Junior's evaluation much better? Please don't misunderstand >>me. I am sure it has a great evaluation but, one may think that when things are >>almost free you could just add any bit of knowledge that you might consider >>useful under any circumstance and have a really astounding, hypergreat, out of >>this world evaluation. >> > >Because the problem is not writing evaluation terms but deciding which one's are >right or formulating them correctly. Not to mention giving them correct weight. > >I don't know where many posters in this newsgroup get the idea that "knowledge" >in chess is obvious and it's just a matter of coding it. In fact the opposite is >true: the *true* and *correct* rules of evaluation ar more like a hidden mystery >that programmers look for like the mathematicians looked for the proof of >Fermat's theorem. I can easily add 20 new elements to my evaluation, but I >expect 19 of them will prove to be wrong, or (what amounts to the same thing), >badly tuned. > >The best way to become familiar with this problem is to write a chess program. I've seen programmers complain about this problem before. They also complain that they apply knowledge to fix a problem in one type of position, and it plays worse in another type of position. I've long believed that the solution is to be more systematic in the creation, storage, and selection of knowledge. I'm afraid I'm not going to write a chess program in the forseeable future, but here's my idea to store knowledge systematically, then address the problem of getting to the right knowledge in the right positions: * write a large number of evaluation functions (eval fn), and store them in a database (db) so that they can be managed and maintained (one eval fn per db record) * for each record, as well as the eval fn, also store some "indexes" to indicate the type of position where this eval fn will be useful * generate a chess position to evaluate (we're playing a game now) * compare this position with the indexes of the eval fns, creating a (percentage?) match value between each eval fn, and the present position * sort the eval fns into order of match value, and pick the best matching eval fns * apply each of the selected eval fns to the present position, weighting them according to their match value * do all this with some sort of "in memory" database with fast APIs, and do some tricks with the database indexing, so that it can all be done quickly in "real time" (I can post a web site of a product that can do this, if anyone is interested). I hope this stimulates further discussion - I personally think that this is a very important issue. After all - we're trying to do "Artificial Intelligence" here - and you can't really be intelligent without having both plenty of knowledge, and the ability to select the right sliver of that knowledge for the present circumstances. -g
This page took 0.02 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.