libkombilo  0.8
Public Member Functions | Data Fields
Algo_finalpos Class Reference

#include <algos.h>

Inheritance diagram for Algo_finalpos:
Algorithm

Public Member Functions

 Algo_finalpos (int bsize, SnapshotVector DATA)
 
void initialize_process ()
 Called by GameList::start_processing.
 
void newgame_process (int game_id)
 Called when a new game is about to be GameList::process'ed.
 
void AB_process (int x, int y)
 Called during processing, for each AB SGF tag.
 
void AW_process (int x, int y)
 Called during processing, for each AW SGF tag.
 
void AE_process (int x, int y, char removed)
 Called during processing, for each AE SGF tag.
 
void endOfNode_process ()
 Called during processing, after fully processing a node (which might contain several AB, AW tags)
 
void move_process (Move m)
 Called during processing, for each move (B, W tags)
 
void pass_process ()
 Called during processing, for each pass.
 
void branchpoint_process ()
 Called during processing, for each node where a variation starts.
 
void endOfVariation_process ()
 Called during processing, when reaching the end of variation ("jump back to most recent branchpoint")
 
void endgame_process (bool commit=true)
 Called during processing, when the end of the game is reached.
 
void finalize_process ()
 Called by GameList::finalize_processing.
 
hashtype get_current_fphash ()
 
hashtype get_fphash (int index)
 
SnapshotVector get_data ()
 Extract the relevant data from file at Kombilo startup.
 
int search (PatternList &patternList, GameList &gl, SearchOptions &options)
 pattern search
 
- Public Member Functions inherited from Algorithm
 Algorithm (int bsize)
 

Data Fields

char * fp
 
int fpIndex
 
std::vector< pair< int, char * > > data
 
- Data Fields inherited from Algorithm
int gid
 store the game id during processing
 
int boardsize
 board size
 

Detailed Description

The basic idea of this algorithm is to compare a given pattern with the final position of the game in order to find all positions on the board where the given pattern could possibly occur. "Final position" has to be understood in the right sense. More precisely, when creating the corresponding database, we record, for each point on the board, whether at some time during the game, a black stone or a white stone is placed there. Of course, with captures and under the stones play, it can happen that at a certain point there is a black as well as a white stone at some time.

The output of the finalpos algorithm is a list of candidates which have then to be checked using another algorithm (see AlgoMovelist).

This comparison against the "final position" of course gives us information only from those points in the search pattern which are non-empty. Hence to reduce the time needed for these comparisons, we use the smallest rectangle inside the original pattern which contains all of its stones, i.e. we cut off the exterior rows/columns which are empty.


The documentation for this class was generated from the following files: