Author: Bob Durrett
Date: 08:47:40 11/10/00
What's wrong with this idea, other than the fact that someone else may have thought of it first? 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.
This page took 0.01 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.