[Human Chess Skill, Charness, p.34-53]
p.34-35 Should a computer be more like a man when it comes to playing chess? ...Perhaps
the clinching argument in favour of the first line of thought [a more exact simulation of human chess players by computers]
is that if your goal is to develop a program which can beat the best human player, a guaranteed solution is to have
the program simulate human playing methods almost exactly.
p.37 In the final analysis, perception seems to be the key to skill in chess... The difference between
two players [when one defeats the other in a game] is usually that one looks at the promising moves, and the other spends
his time going down blind alleys.
p.52 Computers also use heuristics but often the heuristics are not sensitive enough to the context of the
board position."
[An Introduction to Computer Chess, Frey, p.54-81]
p.61 Our experience in computer chess over the past few years seems to indicate that future chess
programs will probably benefit from evaluation functions that alter as the general chess environment changes.
[Chess 4.5 - The Northwestern University Chess Program, Slate & Atkins, p.82-118]
p.83 If there is anything more useless than yesterday's newspaper, it is last year's chess
program... [Chess 3.6, Slate and Atkin's out of date computer program] was an old-fashioned program that depended
on the searching of large trees filled with unlikely positions. It was poorly documented and not very modular. The instructions
that formed the evaluation function were nearly unreadable. Figuring out how our old program worked was like deciphering hieroglyphics,
and adding anything to it was like writing in ancient Sanskrit. One glance at the listing told us that the program had outlived
its usefulness. It had taught us how not to write a chess program.
p.84 In terms of its organization, CHESS 3.6 was a mess. Not only was it difficult to modify the evaluation
function - it was difficult even to find it in the listing of the program.
p.85 Data base [section title] For each position in the look-ahead tree, CHESS 3.6 maintained certain
data related to that position that were useful for evaluation and move generation. The largest part of this was a table specifying
which pieces attacked which squares. This table suffered from two major problems: it had to be regenerated from scratch
for each position in the tree, and it had no clean, simple format that might have more general utility. In [CHESS] 4.5, we
chose a simple data format which could be used for many purposes, including the construction of attack tables which could
be incrementally updated as the tree search stepped from node to node. Incrementally updating means altering only those aspects
of positional information that actually change due to a move on the board. ...much time is saved if the changes are computed
rather than the entire tables.
p.93-94 The CHESS 4.5 evaluation function... adds several easily computable factors together. The dominating
term is material. The remaining terms are rules of thumb designed to give the program a vague positional sense. Rather than
expressing some theoretically rigorous chess principles, these factors merely improve somewhat over "aimless" moves. The design
motive for the evaluator appears to be a self-fulfilling prophecy: we knew that it was going to be primitive and would thus
depend heavily on tree searching. To do such deep tree searching would require that the evaluator do its work quickly, and
so it wouldn't have the time to do anything clever, and thus would have to be primitive.
p.101 On a CDC 6400 CHESS 4.5 processes from 270 to 600 nodes (calls to EVALU8) per second.
p.113 The features of its [CHESS 4.5] evaluation function and tree search were determined often
by the whim of the moment. Certainly they were not the result of a comprehensive, steady, and coherent research plan
designed to exhaust the potential of brute-force tree searching. ... In reality, the program has been a part-time effort,
with long stretches of inactivity punctuated by occasional panicky spurts of attention.
p.115 We conjecture that the better [the evaluation function] already is, the more it will benefit from
a deeper search. If this is true, then we should work on improving the quality of evaluation functions, rather than on small
increments in search efficiency... Our present [evaluation function] is blind to the simplest phenomena. The evaluator
gladly accepts a position in which the computer is a knight ahead although its king is out in the center of the board surrounded
by hostile enemy queens and rooks.
p.116-117-118 ...two major problems in chess programming: the difficulty of specifying chess specific knowledge
to the program and of representing this knowledge internally... The speculative model of chess-program evolution sketched
above is only one of several possible routes to stronger programs. We believe that the common element of any such efforts
is that they involve the addition of more intelligence to chess programs. This intelligence may take many different forms...
In any case, the whole effort to build more intelligent chess programs is just beginning
[Plans, Goals, and Search Strategies for the Selection of a Move in Chess, Church & Church, p.131-156]
p.153 A somewhat slower but more general routine, fills a board with values representing the minimum
number of moves on an occupied board required by a piece (excluding pawns) to move from a given origin square to any destination
square. This calculation is not continued in a given direction when the piece reaches an occupied square or one on which it
would be en prise. [JLJ - an interesting idea - can this heuristic be significantly sped up? Alternatively, we would
continue the piece movement past these points of constraint to ponder what would happen if/when the constraint is removed.]
p.156 It is our belief that the speed and quality of decisions by people and computer programs are improved
when goal-oriented rather than trial-and-error procedures are used... We are convinced that if one wants to design
a computer program to play chess successfully, one must simulate the thought process of strong players... better programs
to play chess can be written if they are based on human thought processes.
[The Heuristic Search: An Alternative to the alpha-beta Minimax Procedure, Harris, p.157-166]
p.157 It seems clear that at least for the endgame, a more sophisticated board evaluator is needed... it
is inevitable that chess programmers must eventually provide a means for representing and using chess knowledge.
p.159 The evaluation function is used more heavily by the heuristic search procedure because it directs
the search in addition to defining the end values.
p.160 our approach is simply to detect the presence of active features, telling the search that it must
continue investigating the active section of the tree in order to receive an accurate rating. The search is ordered primarily
on the basis of the quiescence measure and secondarily on the basis of the static board evaluation. [JLJ - a great idea. We
might have to conceptualize a way to bound this, because it might not be possible to keep going forever in a certain direction
until quiescence is reached in all lines.]
p.166 Therefore the heuristic search approach allows the program to become adequately informed about the
move tree in less time than other search techniques. This reserves as much time as possible to be devoted to the execution
of a very sophisticated evaluation function.
[Man and Machine: Chess Achievements and Chess Thinking, Hearst, p.167-200]
p.170 There is one feature of computer chess that is less often explicitly mentioned as a goal or motivation
for those working in the field - perhaps because it seems less defensible or noble than the other goals, at least to programmers
working in an academic setting. This aspect concerns the aura of competition that pervades the field. Competition
among the designers of different chess programs is keen, perhaps as keen as among human beings competing in serious tourneys
[tournaments], and this factor may in some cases account for why technological refinements, discoveries, and gimmicks [JLJ
- heuristics? ] are often not well publicized by their originators... The publication of a book like the present
volume, composed of contributions from several different groups of workers, may reflect a growing awareness that more cooperation,
rather than more competition, will benefit everyone concerned.
p.176 In summary, the past achievements of computer chessplayers are relatively small... If any
success is to occur, a new or different approach appears to be needed.
p.186 Most workers in the field of computer chess agree that one should strive for a program that
selects its moves in ways as similar as possible to the manner in which a human being makes such decisions. For example,
Newell, Shaw and Simon [74] argued that "any information-processing system - a human, a computer, or any other - that
plays chess successfully will use heuristics generically similar to those used by humans." Botvinnik [18] stated
that we must make the machine "in our image"; "the program must be modeled on human thought processes."
p.193 I agree with de Groot's comment that "incorporating experience into the program, in one form
or another, is not only indispensable but is the very core of the simulation problem," whether one is involved with
expert-level thinking in chess or in some other field.
p.195 Although they will not commit serious blunders, machines rarely are able to produce constructive
moves in positions in which direct threats and tactical possibilities are absent. In such positions, a strong
chessplayer will attempt to reinforce or eliminate his own weak points, and to take aim at his opponent's; long-range
planning is the predominant theme, rather than direct attack. The delicate maneuvers that develop - the "tacking" for small
advantages - may seem boring to the uninitiated but are a major aspect of competition between strong human chessplayers.
p.198 ...attempts to transfer information gained on prior moves for use in subsequent analysis, seem intuitively
worthwhile... [JLJ - but only if this information still applies. ]
p. 200 Perhaps our chances of success in producing a computer chessmaster in the twentieth or twenty-first
century depend on how much more "man" we can put back into the machine - but this time in psychological [heuristic?
- JLJ] rather than physical form.
[18] Botvinnik, M. M., "Computers, Chess and Long-range Planning". New York, 1970.
[74] Newell, Shaw, Simon, "Chess-playing programs and the problem of complexity". IBM J. Res. Develop.,
1958
Quotes from the second edition of this book:
[Belle, Condon & Thompson, p.201-210]
p.201 During the summer of 1972, one of us (KT) [Ken Thompson] wrote a chess program for the PDP-11 [the
predecessor to Belle]. This program played in the 1972 New Jersey Open and also in the 1973 ACM Computer Chess Championship...
The all software version of Belle retired to the ignoble position of /usr/games/chess on distributed UNIX machines.
p.203 This hardware-software combination [an early version of the Ken Thompson-J.H. Condon computer Belle]
competed in the 1977 World Computer Chess Championship held in Toronto. This tournament was the first of
the huge main-frame tournaments. It was estimated that the 16 contestants used computers with a combined cost of $40
million, which would rent for $10 thousand per hour.
