Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: What's Wrong With This Idea?

Author: Bruce Moreland

Date: 12:19:53 11/10/00

Go up one level in this thread


Hitech had modularlized eval, but I never got the sense that it was this broken
up, and it may have been very special case.

There has been some thought about assigning specialties to different chess
engines, running several at once, and having either a human or a computer
analyzer decide which engine to delegate a specific position to.

The typical engine tries to be general-case, because it has to handle not only
special cases, but transitions.  If you have an attacking position, you need to
be able to decide whether or not to trade down into an ending.  So even if you
are in one type of position you can find yourself needing to evaluate positions
that can evolve out of that.

Another difficulty is assigning smooth values to transitions.  You need to
balance scores given for a marginally winning attack as opposed to a winning
endgame, and so on.  Current general-purpose programs have this difficulty as
well, you'll often see them decline to go into a won endgame, or go from a
winning attack into a drawn endgame.

I think that if anything is "wrong" with this it's that you can handle the
different cases in one engine by detecting special material and positional
cases.  That way you don't have to write several engines, you can reuse the 99%
of the stuff that's the same.

My program has dozens of special endgame functions that handle special material
cases (KRB vs KR without tables is the normal eval divided by some constant),
and special positional cases (KBPP vs K is declared drawn if the weaker king is
in the corner, both pawns are rook pawns, and the bishop is "wrong", if any of
these factors is missing the normal eval is called).

I don't know if anyone has gone as schizo about different middlegame
configurations, but that would be something to give thought to.  I believe that
Hitech did load positional weights depending upon what opening it was playing.
I attended a lecture by one of the people who worked on that project, the point
of the lecture was that Hitech had been taught not to play ... c4 as black in
normal French defense positions, through pawn structure tables that were
downloaded when Hitech figured out it was playing the French.

In this case it would be better to teach the program to make good choices
without using crutches like this, but perhaps there are other cases where the
knowledge imparted is more sophisticated.

bruce

On November 10, 2000 at 11:47:40, Bob Durrett wrote:

>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 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.