Authors:

Last updated:

12.12.2010

Platform supported: Mac OS, Linux (i386/amd64)

Libraries to be installed:

1. Sqlite3 installation: (school linux machines do not have libsqlite3-dev library, and we don't have sudo permisson there to install it, so we will demonstrate the program using our own laptop)

   sudo apt-get install sqlite3 libsqlite3-dev

2. Gnuplot installation:

   sudo apt-get install gnuplot

3. Qt installation:
   • Verify that you are in your home directory: cd ~
   • Download the Qt SDK binaries: wget http://goblin.tkk.fi/Qt_SDK_Lin64_offline_v1_1_3_en.run
   • Change the file permissions to make the file executable: chmod u+x Qt_SDK_Lin64_offline_v1_1_3_en.run
   • Execute the installer file and follow the instructions of the graphical installer: ./Qt_SDK_Lin64_offline_v1_1_3_en.run

• Generate makefile: qmake gui.pro
• Compile the program: make
• Execute the program: ./gui

The main window consists of six tab pages: general, hands, sessions, money won, positions and graph. Click "load history file" button to load the history from text file to the database. The file name of the current history file is displayed on the window.

Choose a player in the combo box of players, the statistics will be shown in the tab pages.

On the "general" tab page, the hands history of the current player is displayed in the table of player details. The table of player statistics shows the general statistics.

In the "hands" tab page, the times and winning percentage of different starting hands are shown in the statistics table. The table shows the history filtered by the chosen private cards. When double click a row in the table, the table of session details shows the whole history of the chosen session.

In the "sessions" tab page, by setting the beginning date and ending date, the sessions took place between these two dates are shown in the table. When double click a row in the table, the table of session details shows the whole history of the chosen session. The statistics table shows the statistical results between the two dates.

In the "money won" tab page, the value between 0 and 100 can be chosen by the slider. The table shows the sessions in which the player won money above the value. When double click a row in the table, the table of session details shows the whole history of the chosen session.

The "positions" tab page shows the statistical results for small blind and big blind. The table can also be filered by different positions.

The "graph" tab page shows money won over hands played for the player.

Terminology:

• VPIP %: Voluntarily put money in the pot %
• PFR %: Preflop raise %
• PF3bet %:Preflop 3bet %
• AF %: Agression factor (Raise% + Bet%) / Call %
• Cont. bet flop: Continuation bet flop %
• WTSD %: Went to showdown %
• W$SD %:Won at showdown %
• SB: Small blind
• BB: Big blind

Program architechture

The program includes 5 source files: fileIO.cc, player.cc, sqltest.cc, mainwindow.cc and main.cc. The sqltest.cc includes the interface to the sqlite database. File fileIO.cc provides the function to read from a given text history file, parses every possible line in it, and saves the result in structure in a sqlite database. FIle player.cc includes a player class, which provides methods to calculate player related statistics. In mainwindow.cc and main.cc, we set up graphic user interface using QT. The following is the diagram of the system architecture.

We decided to use this architecture because at the beginning we decided to use sqlite database, then we need a database interface to create and make queries to the databse. The parse module is compulsory to read the history and parse important information, in our design, after extracted information, we directly save it to our database. When looking into our project requirements, we need to make statistics to a given player, so we implemented a statistic module and created a player class, it has methods to get different statistics. To plot the money won, we need to use gnuplot in the system, so we firstly print the dataset to plot in a file, and then call the gnuplot using preconfigured settings, after we got the picture, we embedded it into our graphical UI. The graphical UI can filter through different queries to our database. We think and discuss as well as doing the coding, gradually we get a clear structure of the program like this.

Data structures and algorithms

Peng's data structures:

• The database includes 9 columes. They are: game_date (DATETIME type), game_id (INTEGER type), table_id (TEXT type), action (TEXT type), phase (TEXT type), cards (TEXT type), player (TEXT type), money (REAL type), position (TEXT type). Since I parsed the history line by line, in some cases I can not get all the 9 information at the same time, I just used several records with some entries empty, they are identified by the game_id. We doubted if it is efficient to use text for most of columns and we tried to use integer to replace text in action, phase and position entries, but finally the real problem which caused the slow parsing was found, it was solved in the sql database open settings. In order to make the printed table more readable, we changed everything back to TEXT type at the end.

Nataliia's data structures:

• Following classes were used:
  • Class Player includes methods for statistics calculation and some private variables such as player’s name.
  • Class Database contains methods to work with sqlite3 database: ordinary methods such as open(), close(), etc. and methods for extracting the whole row, counting rows according to a particular query, extracting a single column.

Nataliia's algorithms:

• Hands played: all the games the player took part AND did > 1 actions during the game.
• VPIP: all the hands where a player called or raised or all-in'ed during the preflop phase divided by hands played.
• PFR: all the hands where a player raised or all-in'ed during the preflop phase. divided by hands played.
• Aggresiosn fator: (all raise / total actions) + (all bets / total actions) / (all calls divided / total actions).
• Went to showdown, % = Total Times Went to Showdown / Total Times Saw The Flop * 100, where Total Times Went to Showdown = Times was on river - times folded on river - "not show" cases on river.
• Won at showdown, % = Total Times Won Money at Showdown / Total Times Went to Showdown * 100, where Total Times Won Money at SD were extracted easily, because during our "parsing" phase we marked it as action “winsd”.
• 3bet = Oppurtunities for 3bet / Real 3bet times. In order to calculate oppurtunities for 3bet I chose all the games where a player took part, then all preflop raises among those games. And if the first raise wasn’t done be the player, when our player has an opportunity to bet later. For "Real 3bet" I made the query "SELECT * FROM a WHERE phase=\"preflop\" AND action=\"raise\" group by game_id, player, action, money order by game_id, money;" which showed me all the raises during preflop for each game. Then i just had to calculate how many times the player did 3 bet.
• Continuation bet flop = Opportunities to continuation bet flop / Real continuation bet flop. In order to calculate "Opportunities to continuation bet flop" first I chose all the games where a player raised on preflop. Then among those games I counted how many times a player was on flop phase so had an opportinity to bet again. "Real continuation bet flop": among those sessions where a player raised on preflop exclude those sessions where player's last action was "call". Among those left I counted sessions where a player betted on flop.
• For private cards statistics calculation firstly I found all visible player's hands and their frequency using the single query. Then for each card I extracted the session history and analyzed if the player won this session or not.
• For calculation stats while being small/big blind I used previously written functions (vpip(), pfr(), wsd()) using game_id where a player was on SB/BB as a filter to them.

Qiuyang's data structures:

Known bugs

Nataliia's bugs:

• Our AF value doesnt equal to that in PockerTracker. However, the numbers which are used to calculate AF, i.e. raise%, call% and bet% are the same. It is still unknown for me how PocketTracker calculates the AF.
• PockerTracker calculates total 3bet value. As for us we calculated just Preflop 3 bet value as was needed in the requrements. So we couldnt comare the values. However, I chacked manualy all the seesions where a particaular player did preflop 3 bet and that seems the same in PocketTracker.
• Continuation bet flop appered difficult statistics for calculation, due to the fact, that none of us are good in poker game. Knowing that, in some case it can be slightly not precise.

Peng's bugs:

Tasks sharing and schedule

Liu Peng

Tang Qiuyang

Nataliia Trifonova

Communication:

Amount of work done in different phases:

• Planning: 2 weeks
• Implementation of different areas of project: 3 weeks
• Testing and documentation: 1 week

Things to be improved:

Differences to the original plan

Among "Additional requirements" we did not implement calculation pot odds to improve hand review, because we added much more statistics and pot odds calculation seems not that easy.

Among "More stats and features, e.g. tip a dealer, burn cards before draw, etc." requirements we implemented position statistics and added stats for a player when he/she was on big blind/small blind. "Tip a dealer and burn cards before draw" are the actions which made during the game. This part we just did not delete when we eventually understood the aim of the project (programming not the game, but statistical SW)

Program architecture was changed and is described in the corresponding part in details. Briefly, we had class Player and class Database which contains methods to work with DB. And basically, we didnt have any Data manager as we read history directly to the DB and then by making queries and some code calculat the statistics.

As for "Task sharing" part some changes were made as well. They will be described in the corresponding part. Of course, deadlines where shifted and we had a way more meetings.

We think our plan was not bad, since it covered the main actions each should do, the main ideas of what our programm should calculate and present, gave us rough orientation to deadlines and approximate scope of the work. In any case sometimes it is difficult to stick to the plan.

References

SQLite documentation: http://www.sqlite.org/docs.html

SQLite code example: http://www.dreamincode.net/forums/topic/122300-sqlite-in-c/

C++ documentaion: http://www.cplusplus.com/reference/

Qt documentation: http://doc.qt.digia.com/

A brief gnuplot tutorial by Henri Gavin: http://people.duke.edu/~hpgavin/gnuplot.html