Author: Graham Laight
Date: 04:38:27 07/20/00
Go up one level in this thread
On July 20, 2000 at 04:14:04, Amir Ban wrote: >On July 20, 2000 at 03:13:47, blass uri wrote: > >>On July 20, 2000 at 02:38:07, Ed Schröder wrote: >> >>>On July 19, 2000 at 18:36:28, Graham Laight wrote: >>> >>>>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 >>> >>>You are missing some main points which Amir explained quite well. I will >>>give a very simple example about one of the main problems implementing >>>new chess knowledge. >>> >>>Suppose you are adding new chess knowledge concerning rook moblity on open >>>files. It will have effect on all the other chess knowledge you have written >>>once before. You for instance will get unwanted side effects concerning pawn >>>structure, king safety etc. Unwanted negative side effects can be: a) the >>>engine will accept double pawns too easy because the rook wants to have >>>the open file b) making unsound moves regarding king safety as open rook >>>file is rewarded too high in respect to king safety. >>> >>>The opposite is also true for (a) and (b). Often a position requires to >>>accept the weakness of a double pawn, often a position requires an open >>>rook file above king safety. >>> >>>This is just one of the simple cases. CC is not about just coding new chess >>>knowledge (that is the most easy part) but how it correlates with all the >>>other stuff you have. And the more you have the more difficult it becomes >>>to add new chess knowledge because of these unwanted side effects. If you >>>for instance forget to check (test) chess knowledge you have programmed 5 >>>years ago if it still correlates with the new stuff and it doest not correlate >>>you end-up with a program that is weaker without realizing it (for years). >> >>I agree about the small part of the evaluation but >>I think that programs have problems in evaluating the big parts and in this case >>I do not think that correlation with the old stuff is important. >> >>Example:many programs do not know to evaluate unstopped passed pawns in queen >>endgame. >> >>I remember that many programs did not see that kasparov is the only player who >>has winning chances in his game against the world when it was clear for humans >>that inspite of the fact that kasparov is a pawn down his pawn is more >>dangerous. >> >>Here is another example that I composed with the same subject: >>[D]q6k/5ppp/P1p5/8/8/8/8/Q3K3 b - - 0 1 >> >>In this position it is clear that white is the only player who can win(it may be >>a win for white or a draw by perpetual check but many programs give black >>advantage. >> >>The evaluation should not be a simple sum of numbers but the program should >>evaluate if one side has an unstoppable passed pawn and if it has unstopped >>passed pawn it can decide that all the other pawns are 1/10 of their regular >>value. >> >>Uri > >In the position you gave, if the black pawn is on c7 rather than c6, black wins >immediately. If the black king side pawns are arranged slightly differently, the >probable result is a draw. > >You have given just the right example to show the problem: The outcome depends >on concrete stuff (i.e. tactics). Static evaluation in such a position can only >reflect the probable outcome with this kind of setup. How to do this correctly >is a real problem that can keep a programmer busy for a year. > >You are kidding yourself and this newsgroup that it is possible to evaluate this >position as a win for white and dismiss black's chances without getting into >tactics. If this position came up as the endpoint in a search, the eval fn would have to make an assessment as to who was best here. It's easy to see how mistakes could be made! However, if this position came up somewhere before the endpoint then, in order to be able to assess it correctly, the system would need sufficiently good knowledge to guide the search extensions correctly, to determine which side was going to get a big advantage. There may well be similar positions, however, where lots of extra (time consuming) searching is not going to yield any useful information. How do you know which situation you're in unless you have both bucketfulls of knowledge, and the capability to select the right knowledge for the occasion? -g >Amir
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.