Author: Bob Durrett
Date: 09:27:06 12/22/03
Go up one level in this thread
On December 22, 2003 at 11:41:14, Duncan Roberts wrote: >On December 22, 2003 at 10:47:30, Bob Durrett wrote: > >>On December 22, 2003 at 07:08:09, Duncan Roberts wrote: >> >>>Different software engines have different strengths and weaknesses in different >>>types of positions and I once saw mentioned the idea that one could raise the >>>elo level of chess software by 150 points by having some software which would >>>interface with the top 5 programs and would have all of the strengths and none >>>of the weaknesses of each individual program. This would be achieved as the >>>interface program would ask the individual program to only play the type of >>>position it played best at. >>> >>>kasparov once mentioned that in certain positions junior plays at 150 elo points >>>higher than the competition, on the other hand he said fritz is more 'certain'. >>> >>>An interface program should be a far tougher challenge for kasparov to crack. It >>>would truly reflect the best of computer science against the best chess player. >>> >>>I do not know much about computer chess, but I assume that to implement this in >>>at least a basic way should not take a great deal of time. (a week ?) >>> >>>Is this right? and if so (although it is easy to ask) why is nobody doing it.? >>> >>>There must be many good programmers on this site whose chess programs while good >>>cannot realistically hope to reach the 'top 10'. Surely (assuming the top 5 >>>chess program authors co-operate with this) they would be making a much bigger >>>contribution to computer chess by implementing an interface program. >>> >>> >>> >>> >>> >>>duncan roberts >> >>You may be satisfied with the following approach: [Incidentally, thinking at >>such a top-level does NOT require someone proficient at coding.] > >true but to implement it would require someone proficient at coding. > >>A team of qualified humans could, in advance, work out a set of criteria for >>selection of the engine to analyze a particular position. >> >>The task of the controller program would be to assess the current position in >>terms of the criteria pre-selected by the humans. The controller program would >>then select the engine to evaluate the position. Then the chosen engine would >>be turned on and given a certain amount of time to produce an answer. The >>answer, and hence the resulting position would then be sent, by the controller >>program, to a GUI [or to one of Hyatt's UIs. : ) ] >> >>Then the controller program would begin evaluation of the next position to see >>how it meets the criteria. The process would repeat. At no time would more >>than one engine be working. Only one microprocessor would be needed. >> >>The key point is that the controller program would not have to be an engine. It >>would not contain searching and position evaluation software of the sort found >>in a typical modern chess engine. The "position evaluation" to return a >>numerical evaluation score would not be needed. Instead, all the controller >>program would have to do is check the position against the criteria. >> >>In spite of the conceptual simplicity of this idea, it might take a normal >>programmer awhile to create and debug it. The real time-consuming task would >>not be for programmers but for the team of humans who had to come up with the >>criteria. >> >>Is this what you had in mind? >> >>Bob D. > >yes this is the idea that I once saw being discussed on this forum. > >While to get a perfectly implemented system with about 25 different criteria >may take months of work, what I did not quite understand is that to do it in a >basic crude way it could look just at open, closed, blocked, beginning , >middle and end game. > >Th code to recognise each of these different types of positions is I assume >publicly available. > >also the strenghts and weaknesses of all top programs is widely discussed and >known. > >So in theory it should not be more than a week's work to do it and get a >potential gain of 100 elo points. > >what are people waiting for? > > >Duncan (1) In all fairness, if you were the kind of "competent computer chess programmer" you require, you could do the coding yourself. If you are not, you may not be in a very good position to judge the amount of time and effort required for working out the details, coding and debugging. : ) (2) You seem to have a good idea to do an initial "proof of concept" test using a very simple [almost arbitrary] set of criteria, just to check out the software. This would not evaluate the ultimate potential of the overall idea but would help in debugging. (3) The code to recognize whether a position is "open, closed, blocked, beginning, middle and end game" may not have been written yet but I, too, suspect that the programming for that would be easy enough. If nothing else, it might be an interesting exercise. Presumably a typical position evaluation subroutine in a modern chess engine could be drastically pared down to provide this required capability while deleting all else. [Maybe it would be easier to just start from scratch?] (4) Your perception is that "The strenghts and weaknesses of all top programs is widely discussed and known." I'm not so sure about that. It may be true at a very top level, but when you get into the nitty-gritty of position evaluations, the task may not be so simple. Much time and effort is expended here at CCC looking at special positions where some engine had difficulty [ex: took too long] finding the correct move. The number of positions seems endless. The difficulty one engine has with a program today may be gone tomorrow because the programmer fixes the bug. (5) Special attention needs to be paid to endgame and opening phases, not to mention transitions between phases. (6) Consider endgames first. It is typical nowadays to use endgame tablebases. When the main engine evaluates a multiple piece endgame, it may look at a line where exchanges reduce the number of pieces down to the smaller number such that endgame tablebases can be used. In such a case, the main engine "asks" the tablebase software to return an evaluation. [This surely is a gross oversimplification and ignores GUI or UI roles.] In the new idea, this process may have to be accommodated. In this case, the main engine would continue "running" [maybe in a wait state] while it was waiting for the desired information. (7) It is also typical for chess-playing programs to use opening books. Perhaps no special accommodation would be needed. (8) A new kind of GUI [or UI] might be required. (9) The idea may be generalized. [I would like to know what others think about this generalization.] We have been talking about using a set of distinct popular chess-playing programs such as Shredder, King, Hiarcs, etc. But the concept could be used internally within a new chess-playing program. The "different" engines could in fact be just subprograms within a larger program. The whole mess, in fact, could be packaged in a single program, [probably a whole lot smaller than Crafty. : ) ] Bob D.
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.