Author: Bob Durrett
Date: 19:32:23 11/09/00
Go up one level in this thread
On November 09, 2000 at 13:29:26, William H Rogers wrote: <snip> >If you could put down on paper what kinds of decisions that a program could make >and how it could make it in the mid-game or anywhere else in the program, then >let us all know, as it would be a great next step in computer chess programming. >I am sure that every serious chess programmer is racking his or her brains to >come up with some better evaluations, after all, that is the real heart of a >program as the industry is concerned right now. However, some are just waiting >for faster machines.?? >Bill Consider the possibility of having a block of software [a module] dedicated to a specific situation on the chessboard. For example, consider a situation where an attack is indicated by the position on the chessboard. Consider, also, having another block of software dedicated to some other situation, such as where the opponent’s position is cramped. Going further, consider having quite a few modules of this type for each of the situations that can occur on the chessboard, such that a different general strategy is indicated for each. Each module could be almost dormant during normal play, almost asleep on the hard disk, taking up insignificant computer resources, such as processor time or RAM space. Nowadays, people have very large hard drives, so space occupied on hard drives should not be a concern. A very small bit of software dedicated to each module would reside on RAM and would operate but would do so only at a very low level since this software would have only a very small task, i.e. to monitor certain parameters. For example, the software on RAM associated with attack would monitor certain parameters or features. As a trivial example, consider the Advance Variation of the French Defense. After just two moves for each side, the pawn structure indicates that White should play for a kingside attack. Should the RAM-resident software associated with the attack module detect that an attack might be worth considering, then a part of the Attack Module would “wake up,” moving at least in part to RAM, and taking up a greater percentage of the processor’s time. This software would then start evaluating NEW parameters or features associated with the task of evaluating the appropriateness of beginning an attack. Should the new, more complete, evaluations strongly indicate that an attack is appropriate, then more of the Attack Module would “wake up” [i.e. be transferred to RAM and start using a greater percentage of the processor’s time.] At this point, the RAM-resident portion of the Attack Module would be more sophisticated and might begin evaluation of candidate attack scenarios, as well as doing a more complete set of evaluations, including piece placement, etc. After one or more additional stages, the time might come when most of the software normally used in the chess engine would be almost inactive [bypassed or “put on hold”] and the attack module would be using almost all of the processor and RAM. This idea, as presented above, is possibly too simplistic since the issues associated with competition between modules and turning off of modules after their usefulness has ended has not been discussed above. Also, in certain cases, more than one module might be at least partially awake at the same time. [details, details, . . . ] In this concept, it is seen that there could be MANY parameters, etc., which would not be evaluated in normal operation but which would be after their associated module had awakened. The only limitations on the number of parameters would be the patience and stamina of the programmers, assuming effectively unlimited space available on the hard disk. Generally, the more complex the total package the more opportunities there would be for learning. The total number of “parameters” could be almost limitless since only a few would actively be being evaluated at any one time. “Tweaking of Parameters” could take on a new meaning in this case. To go one step further, the modules could, themselves, be modular. The program could learn when to activate a module or sub-module. My perception is that "high I.Q." can only be achieved by making the total software package more complex.
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.