View
234
Download
0
Category
Preview:
Citation preview
DCS 28 June 2015
1
Dynamic Move Chains and Move Tables in Computer Chess
Kieran Greer, Distributed Computing Systems, Belfast, UK.
http://distributedcomputingsystems.co.uk
Version 1.1
Abstract—The idea of dynamic move chains has been described in a preceding paper [8]. It allows
the search tree to be forward-pruned, which is known to be dangerous, because it can remove
important moves that would only be evaluated through a more exhaustive search process. This
paper has added to the forward-pruning technique, through the use of ‘Move Tables’ that can act in
the same way as Transposition Tables, but for moves not positions. They use an efficient memory
structure and have put the design into the context of short or long-term memories. The forward-
pruning technique can also be fortified, to help to remove some of the error. For example, a
minimum beam width can guarantee x dynamic moves are searched, making the result more
reliable. Or a minimum window for the evaluation difference can determine if a full search is
subsequently required. Therefore, with some configuration, dynamic move chains can be reliably
used and relatively independently of the position. This has advanced some of the future work theory
of the earlier paper as well and made more explicit where logical plans or more knowledge-based
approaches might be applied.
Index Terms— Move table, dynamic move sequence, tree searching, memory structure, knowledge.
1 Introduction
The idea of dynamic move chains has been described in a preceding paper [8]. It
incorporates the idea of forward-pruning the search tree, which is known to be dangerous,
because it can remove important moves that would only be evaluated through a more
exhaustive search process. Forward-pruning techniques make assumptions about parts of
the search tree and remove them without prior evaluation. If this decision is based on a lot
of knowledge, then it might be OK, but as computer chess programs are mainly statistical,
they do not typically contain enough knowledge about any single position or move, to make
that assumption. Therefore, a technique that can use a limited amount of knowledge to
forward prune and still be reliable would be very useful. This paper suggests such a
technique. The amount of knowledge that any chess program contains is still limited and so
it must evaluate many more positions to produce reliable results. Even if evolutionary
DCS 28 June 2015
2
methods or machine learning is used to generate the evaluation function [7], the
understanding level is still very shallow, maybe not more than a set of weight values. The
computer program could therefore still be helped by a friendlier framework for generating
knowledge. The intention of dynamic move chains is to store sequences of moves, rather
than positions with evaluations. The move sequences can then be tried in any relevant
position, where the fact that positions vary only slightly from one ply to the next is helpful.
This means that a move sequence that gets stored has a higher probability of being relevant
to the next position as well, and so on. The sequences are stored in lists called chains, that
might spawn tree-like structures, but in practice so far, are not very deep structures. Even if
the first move does not forward prune, any subsequent moves in the path would and the
fact that moves can be tried and failed means that there is still a large statistical element to
it. The term ‘chain’ is used to try to distinguish from the more common term ‘sequence’.
There are no recognised cycles in the stored moves, but the search process itself does cycle.
So this immediate evaluation result can be used to radically prune the search tree.
As a move chain is created from a cut-off sequence, it does represent the better moves in a
position. It is however very dynamic, constantly changing to the new circumstance that
should also be the most relevant. If thinking about the human process, then this type of
immediate situation is very relevant, but we also store all of these situations into a longer-
term memory that is built-up more slowly. When we are faced with an immediate situation
again, we can still retrieve from the long-term memory, helpful advice for what to do. It
happens to be the case that the move chains can be used to build up a type of longer-term
memory for the computer program as well. It is similar to transposition tables, but as
described in the following sections, is indexed by moves and not positions. This is possibly
just completing the move chains idea that was reported previously and can give the search
process more reliability or stability when using forward-pruning.
The rest of the paper is structured as follows: section 2 gives a recap of the dynamic move
sequences. Section 3 notes some related work, similar to the earlier paper. Section 4
describes the new Move Tables idea, while section 5 gives some test results from using it.
Section 6 describes how the forward pruning technique has been implemented as part of a
chess game-playing program. Section 7 gives a discussion, including where more knowledge-
DCS 28 June 2015
3
based approaches might benefit from the new structure, while section 8 gives some
conclusions on the work.
2 Dynamic Move Chains
Dynamic move chains [8] can be created from the cut-off move sequences of the search
process. A cut-off is generated when a move sequence is found to refute a particular
position and means that further search of the position is not required. It can also be when
the α-β value is changed, updating the allowed search window. The move sequence can
then be the current search path and it can be stored and retrieved later, to replace a full
search. Even very small changes in a position however can produce very different
evaluations and so it is not possible to give a definitive result based on this type of move
sequence alone. The move sequence must be played and re-evaluated again in any position
that it is applied to, but the fact that positions vary only slightly from one ply to the next
helps to ensure that the move sequence might still be relevant. If it is found to be
unreliable, it can simply be ignored and the next cut-off might produce a completely
different move sequence to be saved and tried again, for example.
The algorithm for the dynamic move chains is also provided in the paper [8], where the new
Move Tables search part would be placed at the top, before any of the other searches. The
same move sequence can be stored in a more permanent structure that might be compared
to a longer-term memory, for example. This structure can be built around piece types,
where each piece type can be represented by a board-sized array. A weight value is
incremented if a move is added and decremented if a move is not used. If the weight
exceeds a threshold, then the move sequence can be retrieved and tried in the position. It is
even possible to try only a particular number of stored moves, making it configurable. This is
described further in section 4, but the addition to the algorithm might look like the pseudo-
code in Figure 1. So a standard search can incorporate both the immediate and long-term
dynamic move paths. If a beam width ensures that x move table paths are always played,
then even if they are radically forward pruned, the next path will still provide more
information. This should give added stability and reliability about the returned evaluation.
DCS 28 June 2015
4
Section 6 extends the algorithm further, to what has been implemented as part of a chess
game-playing program.
Figure 1. Addition to the algorithm of [8], for where the Move Tables can be used.
3 Related Work
This paper is a follow on from the earlier paper [8] that describes the new forward-pruning
method in detail. It therefore mostly extends the ideas of that paper to give more validity to
it. Related research would still be the original Chessmaps Heuristic paper [9], the Killer
Heuristic [11][2], the History Heuristic or Transposition Tables [13][14], for example. The
Chessmaps Heuristic is the move-ordering algorithm and its square control can also be used
by the quiescence search. The Killer Heuristic is another type of immediate result. It can
store a killer or best move for each level of the search tree, based on the idea that in many
positions, the same move of the opponent will be the best after ‘any’ move by oneself. It is
not the same as a move chain however. The killer move would be tried first, but would not
forward-prune, for example. Another example of storing moves instead of positions is the
Countermove Heuristic [15]. It is based on the observation that in many different positions a
particular move is best responded to by some particular opposing move. An economic
storage structure can be used to store the moves and also the counter moves. It was shown
to reduce the search by as much as 20 – 50%, but there are differences with Move Tables.
Move Tables are retrieved by positions to continue one’s own move sequence and not to
counter any other move. The new idea is maybe more knowledge-based as well. Knowledge
is maybe a generalisation of something, while these other heuristics were maybe more
moveList = generateMoves(); mtPaths = getMtPaths(); select top x mtPaths to search over remove top x mtPaths from moveList search each mtPath as standard search first while (moveList not empty) { get next move in move list get dynamic move chain starting with the move if chain exists, play it if not play full a-b search }
DCS 28 June 2015
5
tactical. The History Heuristic uses a similar type of compact storage structure that the move
tables have adopted and Transposition Tables are position-indexed versions of the move-
indexed Move Tables.
As described in section 7.1, Botvinnik’s knowledge-based approach [3][4] might now be
relevant. Even though it was found to be insufficient at the time, some new ideas could
improve the research potential. With relation to writing a game-playing program, the
following blog [12] is interesting. It actually quantifies the reason why forward-pruning
should not work, which is helpful for making comparisons with. There are lots of other more
recent search algorithms and some have been written about in earlier papers, [8] for
example. The strongly AI-based heuristics are often use to learn evaluation functions and
the Move Tables or Move Chains seem to have more in common with these earlier attempts
that relied on compact storage structures and reactionary or very basic updates, resulting
from reliable evaluations in the search process. The more knowledge-intensive processing
would be part of the next phase that builds on the information that the Move Tables
provide, see section 4. The ‘Method of Analogies’ [1] has been suggested and was
implemented as part of the Deep Blue program1 [10]. In the summary they state that:
‘… a game-playing algorithm often inspects the same thing many times over. A human, having
studied a situation once, will in the future draw conclusions by the use of analogy. But, it often
happens that seemingly insignificant changes in the position alter the course of the game and
lead to substantially different outcomes.’
Therefore, specific features and knowledge are required to determine these differences.
Section 4 suggests some new techniques that might be tried, to generate some low-level
knowledge automatically, as with Botvinnik’s problem.
4 Move Tables
The Move Tables are intended to replace the function of Transposition Tables. There are lots
of different heuristics that can be used together in a program, and Move Tables and
1 Reviewer comment.
DCS 28 June 2015
6
Transposition Tables might both be used. But as they represent the same type of memory
structure, result measurements might get confused. This is not for performance
considerations, where Transposition Tables are proven, but for research reasons. If you like,
switch one feature off so that you can more easily measure the effects of another one. A
Transposition Table is really a huge database and is not knowledge-based, but there is no
intention to go into competition with it, Move Tables are just a different research idea. They
have been given the ‘Move’ name to distinguish indexing on moves with indexing on
positions. They can be considered as a long-term memory of the chess game that can span
the whole game and not just a single move. This is to complement the immediate effect of
the current Move Chains [8] produced from the cut-offs. They have some advantages and
some disadvantages over Transposition Tables. For one thing, they can be encapsulated in
an array that is the size of a board. They can also be stored for each piece type, for both
colours requiring a total of 12 tables, but this is still a relatively small amount of memory
compared to Transposition Tables. The enhancement of the table then, is paths of moves
that grow from them and would also link from one table to another one. Figure 2 is an
example of what the move tables might look like.
Figure 2. Example of Move Tables and Links between them.
The large squares represent the move tables for each piece type and can literally be only 64
elements in size. They then also store any number of links between themselves. The smaller
squares represent the move sequence that has just been added, resulting in incrementing
those related weight values only. Consider a cut-off that has resulted in a move sequence
DCS 28 June 2015
7
such as: WPe2-e4, BPe7-e5, WNg1-f3: This would firstly be stored as the next move chain
sequence, which is currently like a short-term memory that gets used immediately but is
also changed immediately. It is then also used to update the move tables. Both the ‘from’
and ‘to’ move squares can be updated, where the related weight value can be incremented.
All other related move paths can have the weight value decremented, for example. There
can also be a threshold value, where the weight must be above that for the move to be
considered. If an evaluation is found to be unreliable however, the move chain does not
have to be removed immediately, but can have the weight value decremented, until it is
eventually removed. There can also be links between the tables, where the move WPe2-e4
is stored in the e2 square that then links to Black’s Pawn’s table, to the e7 square. That then
links to White’s Knight’s table, to the g1 square, and so on. Any move sequence that is
returned can also be checked for legality in the position as well as weight value. As written
in section 2, a typical minimised search maybe has a branching factor of only 6. The Move
Tables might return more potential moves than this, so they need to be filtered again, to
keep only the top ‘x’ number, as in a beam width. But this can be set to anything and
therefore tailored to the particular program that is using it. Note that the move table is not
reset after each move, but builds up over the whole game. The next search process will add
to it or modify it further, but still retain the information of the earlier searches.
4.1 Best Squares and Important Squares
These move tables then produce a pattern of what the best moves for each piece type is.
This could be very useful information as this type of view could provide a basis for some
level of knowledge-based reasoning. It is also useful that it can be considered individually
for each piece. The Chessmaps program was built from the idea of square control [9], which
is central to generating the move ordering for the computer program. The new Move Tables
also generate this type of information, for individual pieces. However, it could be used
without square control, which is inefficient to calculate, whereas the tables are very quick.
As square control is always part of the Chessmaps heuristic however, it will always be used
as part of this research project.
DCS 28 June 2015
8
If trying to derive some form of knowledge from the move tables, then looking at the best
squares only might not be the most beneficial. Figure 3 shows the Queen and Bishop move
tables for the indicated position, with only the best and positive weights displayed. It clearly
agrees with that position, where the best moves for White indicate to attack Black’s
weakened King’s side. The weighted squares however, only relate to two specific moves,
where negative weight values are not displayed and this might make the table a bit sparse.
If there are several moves from a square, for example, then if one of them is the best, the
others will have their weight values decremented and might become very small, or they
might mutually decrement each other.
Figure 3. Queen and Bishop Move Tables for the shown position.
In Figure 4 however, the accumulated weight values for all of the stored moves for the
White Queen are displayed. Note that the accumulated values have made every square
negative, apart from the squares with the value of 0. These are squares that no moves were
stored for, whereas, even if the values are negative, those squares have been very actively
considered and are therefore important. It is also interesting that the squares with the
largest negative values relate to the best move for the Queen as well, shown in Figure 3. So
there were many considerations around those squares and one idea might be to take the
absolute value of the accumulated weight values to represent a square’s ‘importance’ for a
piece and the best weight value(s) to represent the ‘best’ square(s). An important square
DCS 28 June 2015
9
can then possibly be given priority as part of a plan, for example. To illustrate this, the
second diagram of Figure 4 has coloured in the table, using the absolute weight values only.
The most important squares are coloured red; then orange, yellow, green, light blue and
dark blue is the least important. The white squares should maybe not be considered at all.
Figure 4. Accumulated weight strengths and relative importance map.
5 Testing
The chess-playing program itself and the test program are both written in the C# .Net
language. Two types of test have been carried out. The first is simply some 5-minute games
against the standard Chessmaps Heuristic, so show that using Move Tables with Dynamic
Move Chains does not have a detrimental effect in real play. For this, the number of table
moves to search first was set to a maximum of 4. A random opening for each game would
be selected and there was also iterative deepening with a minimal window. The new
Dynamic Move Chains with Move Tables performed well enough against the standard
Chessmaps Heuristic with Transposition Tables. In ten 5-minute games, it won 7-3.
To see how adding the move tables changes the search size, tests adding 1, 2 and 4 moves
to the start of the Move Chains search process was measured. The paper [9] shows how the
forward pruning approach of using dynamic move chains by itself, can reduce the search by
DCS 28 June 2015
10
as much as 99% more than a standard one and so there is a lot of scope for trying to
broaden the search process by adding extra knowledge or moves. Table 1 gives the results
of the relative search sizes for dynamic move chains with or without the additional move
tables. This was measured over a full game containing 98 separate positions to a depth of 5
ply. The results are for the negamax α-β search stage only and show the number of times
the search size is less rather than the reduction percentage. Note that this result does not
measure move quality, only the search reduction.
Search Type Move Chains Move Chains + Move
tables (1 move)
Move Chains + Move
tables (2 moves)
Move Chains + Move
tables (4 moves)
Av Nodes 545 13367 12117 12550
Times less 23 1 1 1
Table 1. Search reduction for Move Chains, or MC plus Move Tables – 1, 2 or 4 moves.
It is interesting that adding 1 single additional move dramatically increases the search size
(98%), but adding more than 1 move does not have the same increase effect. So if using the
short-term Move Chains by itself, it searches in effect, an average branching factor of 3-4.
Then forcing at least 1 additional long-term move, increases this to 6-7, which is the
standard search size. Forcing more than 1 additional move does not have the same effect.
So further down the search, where all of the cut-off techniques are still used, the new
additions must be compensated in some way, possibly by adding accuracy to the move
ordering. Another stat here suggests that move tables are used maybe only 30% of the time,
as part of the α-β search, or not used 70% of the time, when the dynamic cut-offs can still
occur. But this is for a new table from a single position. If it has built up a picture from
earlier searches, then it would probably be used more than that. While these are only initial
results, the long-term move sequence at least could be a path of legal moves. In practical
terms, this would mean that the narrower short-term search can search much deeper, but
might miss more moves, while the broader (beam width) long-term one is reliable but takes
up most of the spare search time. An ideal balance of both will produce the best search
result. Some games between dynamic move chains, one with and one without the move
DCS 28 June 2015
11
tables, was not conclusive. This is not a voluntary statement of incompetence, even though
the buggy program may have had some problems. It could indicate that a very deep search,
even if it misses a lot of moves, can still play quite well if it returns something that is
reasonable. Especially if captures are generally considered, when the immediate loss based
on material is not as critical. A broader search can maybe manoeuvre better to eventually
force a winning situation.
6 Game-Playing Program
The two forward-pruning techniques have been incorporated into the Chessmaps game-
playing program [5]. To make them more reliable, they have been fortified with some other
checks, but they are still very extensively used during the search and there is even an
argument to reduce them or tidy them up, so that they do not become too large. This
section describes in more detail how they are used. Figure 5 extends the algorithm of Figure
1, to show how it is used as part of the program. Some other points are as follows: For the
immediate or short-term move chains: they get removed if they are unreliable, but they are
immediately added and used if they return a good score later on. For the long-term move
tables: for each increment or decrement update, the evaluation score is added to the stored
move path. This is then averaged with all of the earlier scores and that is used as the general
assessment for the move path. The first evaluation can be as incorrect to the current
position as a later one, for example. The move paths are updated or stored if they produce a
better alpha value. This is not a final cut-off, but a better move and the current path is used
to update the tables. There can be a threshold where weight values below that are not
considered, but the selection of the paths can then be done using the general evaluation
result instead. As the chess position does change, the last time a path was updated can also
be stored and the database tidied up by removing paths that fall outside some move range.
The quiescence search has also been changed slightly. This is played at the end of a search
path and is intended to compensate for the horizon effect of the search process by
producing more stable positions to finally evaluate. As the Chessmaps heuristic evaluates
square control, it is possible to determine what moves are safe captures or safe forced
moves from it. Safe forced means that the piece is in danger but can safely move to another
DCS 28 June 2015
12
square and so both these types of move can be considered in the quiescence search, as well
as king check moves.
Figure 5. General α-β search algorithm in the game-playing program.
If (depth == max_depth) { return quiescence_search(…) } else {
moveList = generateMoves(); mtPaths = getMtPaths(); //long-term move table select top ‘x’ mtPaths to search over //evaluation or weight ordering remove mtPaths from moveList for (i = 0 to mtPaths.length) {
currentEval = mtPaths[i].eval; newEval = path_then_quiescence(mtPath[i]); //play path then quies search at end if (newEval outside window of currentEval) {
mtPaths.decCurrentPath(mtPath[i]); //unreliable so decrement re-add first move to moveList; } else { If (newEval > bestValue) { bestValue = newEval;
} }
} while (moveList not empty) { if (bestValue > alpha) { alpha = bestValue; store currentPath in mtPaths; //reliable so add/update store currentPath in moveChains; //reliable so add } nextMove = moveList.next; movePath = moveChains.getPath(nextMove); //short-term move chain
currentEval = movePath.eval; newEval = path_then_quiescence(movePath); if (newEval outside window of currentEval) {
mtPaths.removeCurrentPath(movePath); //unreliable so remove re-add first move to moveList; } else { If (newEval > bestValue) { bestValue = newEval;
} }
If (no move chain / move chain unreliable) { Standard search with nextMove //standard search with this method again
}
nextMove = moveList.next; }
}
DCS 28 June 2015
13
7 Discussion
Move Tables are similar to Transposition Tables, except that they store move sequences and
not position evaluations. They might be thought of as completing the solution to using Move
Chains, suggested in [8]. It can be used in any position where it is relevant and complements
any immediate cut-off situation presented by a single move chain. As written about in the
earlier paper, the advantage of storing a move is that it is position independent and can
therefore be tried in any relevant position. For chess, the branching factor is still quite small,
but for larger games or problems, the database size for a transposition table might simply
be too large. Being able to store small pieces of information in the form of independent
moves might add useful knowledge. The earlier paper [8] also suggested future work that
can be tried, along the lines of adding more knowledge and some form of narrow
evolutionary search. This even went back to the very beginning and the knowledge-based
feature extraction processes. Move Tables does not solve that problem specifically, but it
does provide some automatic processes that can realistically be used to help with the
knowledge-based approach. As it has been extracted from the search process, it must be
considered as reliable, so the only problem is how to interpret it.
One nice thing is that it would be possible to retrieve any number of moves from the tables
and use them in a relatively independent way. The number retrieved could even be changed
by the program. Or the pattern that each table produces can be studied, to try to determine
key squares, for example. At the very least, they give added information about the relative
positions that a knowledge-based approach might be able to use. The earlier paper also
wrote about tactical chunks, instead of the more common knowledge-based ones [6]. If
there are weight concentrations in a move table, then the related position could be looked
at to see what pieces or piece formations were present. Or if two or more move tables
intersect somewhere, it might represent an important board feature. This could simply be
used to re-order all moves to that particular area, or it might help with creating these
knowledge or tactical chunks. The chunks however would then need to be made part of a
plan and not one that the search process would naturally choose. It would need to change
the natural search process in some way, maybe by re-ordering moves. However, if it is
DCS 28 June 2015
14
automatically created, then it is more in sync with the evaluation function that created it,
rather than an expert saying one thing and the computer program saying another thing.
7.1 Botvinnik’s Computer Chess Theory
The former World Champion Botvinnik wrote a computer chess book [4] and program
(Pioneer) when the chess programs were built on the theories of logic and knowledge. As
computer speeds improved, the statistical brute-force approaches took over and are now
standard. The expert logician suggested in his book, to measure how many moves it might
take for a piece to move from where it is to where it should be. This requires specific
knowledge about the position, but is a bit like narrow sequences that need to be
incorporated into a main search process. This more specific knowledge represents a
particular plan in the position, but if it cannot be built from a rich knowledge-base, then an
experience-based approach could help to generate some low-level knowledge to start with.
Looking at the patterns in each move table shows the squares that the search process has
evaluated as important for each piece. Therefore some counting measure of how to move
between them could be considered, in what would be a more logical and knowledge-based
approach. The chess program is also described in [3], where the following quote from ‘The
Tale of a Small Tree’ chapter sums up some of the relevant philosophy:
‘Thus, during a game a player analyses the movements of a limited number of pieces on a
limited part of the board, and analyses the movements of only those pieces which come
directly into collision, and only on those squares where collisions are possible. In other words,
he examines only those pieces which interact with the enemy pieces, and only those squares
where this interaction is possible. But how can one check that these pieces and these squares
have been correctly chosen? …’
So the move tables can maybe produce a map that can be combined or compared and show
more easily what the squares or pieces might be. While a human player can simply see that,
it might not be as obvious to the chess computer program. So some more elements could be
in place for the knowledge-based approach now, but it is also clear that a lot more work is
still required.
DCS 28 June 2015
15
8 Conclusions
This paper has added to the forward-pruning technique of Dynamic Move Chains, through
the use of Move Tables that can act in the same way as Transposition Tables, but for moves
not positions. They use an efficient memory structure and have put the design into the
context of short or long-term memories. The dynamic move chains cause an immediate
reaction, whereas the move tables build up more slowly and can be used at any time. They
store a more permanent type of knowledge that can represent the whole chess game and
might be compared to a long-term memory. These can allow the search to be broadened,
making it more reliable and are relatively independent, allowing some configuration as to
how much to use. It has advanced some of the future work theory of the earlier paper [8]
and made more explicit where logical plans or more knowledge-based approaches might be
tried. The approach would be used in the first instance, if focusing on a strongly AI-based
program and not one optimised for playing strength. It is also likely that successful results
would be transferrable to other types of game or problem, where the branching factor is
larger. The main improvement in this paper is probably the fact that a forward-pruning
method thought to be unreliable is now valid. This is demonstrated in the game-playing
program [5]. However, forward-pruning will always remove moves and so a question still
remains if the new research has moved the problem from playing a blunder instead of a
reliable move, to playing a reliable move instead of a brilliant one. But too many other
factors are involved in that answer and it would be a particularly nice problem for additional
knowledge to try to solve.
9 References
[1] Adelson-Velsky, G., Arlazarov, V. and Donskoy, M. (1988). Algorithms for Games, Springer.
[2] Birmingham, J. and Kent, P. (1977). Tree searching and tree pruning techniques, Advances in
Computer Chess, Edinburgh University Press, Ed. Clarke, M.R.B., pp. 89-107.
[3] Botvinnik, M.M. (1981). Selected Games 1967 – 1970, Pergamon Russian Chess Series, Pergamon
Press, translated by K.P.Neat.
[4] Botvinnik, M.M. (1970). Computers, Chess, and long range planning, New York: Springer-Verlag.
[5] Chessmaps program, http://distributedcomputingsystems.co.uk/gameplaying.html. (last
accessed 30/6/15).
DCS 28 June 2015
16
[6] Fürnkranz, J., (1995). Machine Learning in Computer Chess: The Next Generation, ICCA Journal,
Vol. 19, No. 3, pp. 147-161.
[7] Fürnkranz, J. (2007). Recent advances in machine learning and game playing. OGAI Journal, Vol.
26, No. 2. Special Issue on Computer Game Playing.
[8] Greer, K. (2013). Tree Pruning for New Search Techniques in Computer Games, Advances in
Artificial Intelligence, Vol. 2013, Article ID 357068, 9 pages. doi:10.1155/2013/357068, Hindawi.
[9] Greer, K., (2000). Computer Chess Move Ordering Schemes Using Move Influence, Artificial
Intelligence Journal, Vol. 120, No. 2, July, pp. 235-250.
[10] Hsu, F. (2002). Behind Deep Blue: Building the Computer that Defeated the World Chess
Champion. Princeton University Press. ISBN 0-691-09065-3.
[11] Huberman, B.J. (1968). A Program to Play Chess End Games, Technical Report, No. CS-106, Ph.D.
Thesis, Stanford University, Computer Science Department.
[12] Laramee, F.D. (2000). Chess Programming Part III: Move Generation,
http://www.gamedev.net/page/resources/_/technical/artificial-intelligence/chess-
programming-part-iii-move-generation-r1126. (last accessed 30/6/15).
[13] Schaeffer J., (1989). The History Heuristic and other Alpha-Beta Search enhancements in
Practice, IEEE Transactions on Pattern Analysis and Machine Intelligence, Vol. 11, No. 11.
[14] Schaeffer J., and Plaat A., (1996). New Advances in Alpha-Beta Searching, Proceedings of the
25th Computer Science Conference.
[15] Uiterwijk, J.W.H.M. (1992). The Countermove Heuristic, ICCA Journal, Vol. 15, pp. 8 – 15, ISSN
0920-234X.
Recommended