dynamic move chains and move tables in computer chess

16
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

Upload: dangminh

Post on 02-Jan-2017

232 views

Category:

Documents


0 download

TRANSCRIPT

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.