10x10 endgame databases
Ron van Bemmelen
What is the state-of-art of endgames databases ?
================================================
Have all 4 pieces endgames been fully analysed?
How about 5 pieces endgames ? 6 pieces ?
How does one check the judgement on EVERY position recorded in the database?
Are these endgames databases realtime available during game-play?
Greetings,
Ron.
Harm Jetten
At the moment I'm generating 10x10 endgame databases for DAM 2.2.
I use Michel Grimminck's DragonDraughts code (see his home page)
and a compression method of my own.
These databases only contain win/draw/loss information, unlike
Gijsbert Wiesenekker's 3-piece and 4-piece databases which include
the distance to win/loss.
I want to use them real-time, so there will be some work involved
in encouraging DAM to make progress while in a particular
database, e.g. 4 kings against one.
The resulting files are only verified by checking whether they are
internally consistent (comparing the position's value with the
min- or max-value of the moves possible from that position).
The 5-piece files are complete, and I have a few 6-piece files.
The last one took a week to complete, and I start to run out
of hard disk space.
I found Jonathan Schaeffer's Chinook book very useful (and
entertaining as well). Too bad I don't have access to hundreds
of workstations or a supercomputer!
Harm.
Jonathan Schaeffer
>What is the state-of-art of endgames databases ?
>================================================
>Have all 4 pieces endgames been fully analysed?
>How about 5 pieces endgames ? 6 pieces ?
I have computed all the 2 through 5-piece databases. They were made
available to Stef Keetman (Truus) a few years ago. I started the
6-piece databases but gave up (lack of interest).
I believe that all the 6&7 piece databases can easily be computed today.
>Are these endgames databases realtime available during game-play?
The databases were constructed so as to be usable in realtime.
Ron van Bemmelen
Perhaps it will be possible to compare your statistics of endgames
databases with mine (4 pcs statistics was posted some time ago and some 5
pcs statistics will be available REAL SOON NOW). By comparing the results
calculated in two different ways, we can both raise our confidence in the
correctness of the databases.
Could you publish some statistics of the 5 piece endgames databases.
Number of positions possible and win-draw-loss for both sides, the maximum
distance, the compressed size per database.
You talk about databases. Does this mean you have several physical
separate files? During the alpha-beta search DAM 2.2 will need endgame
information which will be scattered over several files and 'at random'
positions within the (compressed) files. How will you manage these lookups
(efficiently)? I suppose you can't preload everything in RAM.
I am considering chopping the files in fixed size chunks and storing them
in a huge database and let the database do all the dirty work on caching.
Whether or not I use compression on the win/draw/loss information and/or
the distance to winn/loss, I haven't decided yet. Any suggestions?
There is another problem which i haven't quite solved: finding the exact
value in the databases may take a lot of time (if disk-access is
necessary), in some cases it isn't worth investing that much time, an
quick-and-dirty heuristic value will do the job. How to balance the
quality of the evaluation and the time invested?
Ron.
Ron van Bemmelen
You wrote "I have computed all the 2 through 5-piece databases." In
another posting I am asking Harm Jetten to publish some statistics on the
4 and 5 piece databases, I would like to ask you the same question.
You also wrote "They were made available to Stef Keetman (Truus) a few
years ago." Would you consider making these databases available to me
and/or other authors of draughts programs?
Am I right in supposing that these databases were made available 'a la Ken
Thompson' data-only (no source included) ? Excuse me for using the word
'only'.
I am sorry to hear that you gave up on 10x10 draughts (lack of interest).
I am sure there in The Netherlands several draughts programs who would
like to crush (... or be crushed by ...) a draughts program made by
Jonathan Schaeffer !
Ron.
Gijsbert Wiesenekker
Harm Jetten wrote:
> Ron,
>
> At the moment I'm generating 10x10 endgame databases for DAM 2.2.
> I use Michel Grimminck's DragonDraughts code (see his home page)
> and a compression method of my own.
> These databases only contain win/draw/loss information, unlike
> Gijsbert Wiesenekker's 3-piece and 4-piece databases which include
> the distance to win/loss.
> I want to use them real-time, so there will be some work involved
> in encouraging DAM to make progress while in a particular
> database, e.g. 4 kings against one.
> The resulting files are only verified by checking whether they are
> internally consistent (comparing the position's value with the
> min- or max-value of the moves possible from that position).
> The 5-piece files are complete, and I have a few 6-piece files.
> The last one took a week to complete, and I start to run out
> of hard disk space.
> I found Jonathan Schaeffer's Chinook book very useful (and
> entertaining as well). Too bad I don't have access to hundreds
> of workstations or a supercomputer!
>
> Harm.
>
> rbem...@xs4all.nl (Ron van Bemmelen) wrote:
>
> >(10x10 only)
> >
> >What is the state-of-art of endgames databases ?
> >================================================
> >
> >Have all 4 pieces endgames been fully analysed?
> >How about 5 pieces endgames ? 6 pieces ?
> >
> >How does one check the judgement on EVERY position recorded in the database?
> >
> >Are these endgames databases realtime available during game-play?
> >
> >Greetings,
> >Ron.
Harm,
As far as I remember (please correct me if I'm wrong Jonathan) you should use a
reduced representation (won/draw/lost) while searching (if this representation
can be loaded in RAM). When your program has finally made the transition to the
endgame, you should switch to the extended depth representation, that does not
need to be loaded in RAM, because you do not have to search any more.
Way back, GWD loaded the 3-piece databases in RAM, and accessed the 4-piece
database from disk while searching. An adjustable parameter limited the
search-overhead for accessing the 4-piece databases to 5 seconds, or about 10000
positions.
As far as I remember (please correct me if I'm wrong Klaas), we never gained
anything from the 4-piece endgame database during drauhts tournaments, because
GWD would usually mess up his position during the middlegame, and endgame
databases could not repair that.. That is why we are working now on improving the
middlegame of GWD.
Regards,
Gijsbert
http://www.wxs.nl/~gijsbert.wiesenekker
pc...@nos.pam.co.uk
>rbem...@xs4all.nl (Ron van Bemmelen) writes:
>>What is the state-of-art of endgames databases ?
>>================================================
>>Have all 4 pieces endgames been fully analysed?
>>How about 5 pieces endgames ? 6 pieces ?
>I have computed all the 2 through 5-piece databases. They were made
>available to Stef Keetman (Truus) a few years ago. I started the
>6-piece databases but gave up (lack of interest).
>I believe that all the 6&7 piece databases can easily be computed today.
>>Are these endgames databases realtime available during game-play?
>The databases were constructed so as to be usable in realtime.
Are these databases available in the public domain?
cheers
ade
SAGE/DYNAMO checkers WWW site (inc shareware versions)
http://ourworld.compuserve.com/homepages/pcsol/pcsol.htm
CHESS GENIUS CHESS homepage
http://www.computerchess.de/chessgenius/home_e.html
Harm Jetten
>databases with mine (4 pcs statistics was posted some time ago and some 5
>pcs statistics will be available REAL SOON NOW). By comparing the results
>calculated in two different ways, we can both raise our confidence in the
>correctness of the databases.
>Could you publish some statistics of the 5 piece endgames databases.
>Number of positions possible and win-draw-loss for both sides, the maximum
>distance, the compressed size per database.
I have included the 5 piece statistics at the bottom of this
article. I don't have the maximum distance though.
Jonathan Schaeffer has also published 10x10 database statistics,
see DejaNews article http://x8.dejanews.com/getdoc.xp?AN=159647765
>You talk about databases. Does this mean you have several physical
>separate files? During the alpha-beta search DAM 2.2 will need endgame
>information which will be scattered over several files and 'at random'
>positions within the (compressed) files. How will you manage these lookups
>(efficiently)? I suppose you can't preload everything in RAM.
Yes, I have 44 separate 5-piece compressed files.
Win32 has a method of mapping a view of a file to virtual memory,
where the user gets a pointer and can do random access as if it were a
regular array. The kernel arranges all the housekeeping, paging into
physical RAM etc. Very neat, works on both NT and 95/98. (The API calls are:
CreateFile(), CreateFileMapping(), MapViewOfFile()).
>I am considering chopping the files in fixed size chunks and storing them
>in a huge database and let the database do all the dirty work on caching.
>Whether or not I use compression on the win/draw/loss information and/or
>the distance to winn/loss, I haven't decided yet. Any suggestions?
Having the distance to win/loss is expensive.
My 4-piece databases include the distance to win/loss, they are 20 MB
compressed. The new 5-piece files with win/draw/loss are only 49 MB,
with each file containing its own index table.
I do use the trick of excluding capture positions in those files,
replacing their values with the "dominant" value, a la Chinook.
That improves the compression ratio enormously. I don't exclude
capture threat positions, I might try that later if I need still better
compression.
Before accessing the databases, capture positions first have to be played
out by the search routine, I let the quiescence code take care of that.
>There is another problem which i haven't quite solved: finding the exact
>value in the databases may take a lot of time (if disk-access is
>necessary), in some cases it isn't worth investing that much time, an
>quick-and-dirty heuristic value will do the job. How to balance the
>quality of the evaluation and the time invested?
Designing good(enough) heuristics takes a lot of effort...
Harm.
=================
Naming convention: <sidetomove>v<otherside>
X = king, O = man
database OOOOvO: win: 6087296 draw: 87717 loss: 2
database OOOOvX: win: 4631683 draw: 2215868 loss: 6219
database OOOvOO: win: 6582139 draw: 5631732 loss: 202809
database OOOvXO: win: 3133756 draw: 19375490 loss: 5123414
database OOOvXX: win: 253012 draw: 9487647 loss: 5598731
database OOvOOO: win: 1312598 draw: 7643214 loss: 3460868
database OOvXOO: win: 1007304 draw: 18364875 loss: 22186061
database OOvXXO: win: 293125 draw: 14796785 loss: 31166080
database OOvXXX: win: 23331 draw: 4370072 loss: 12729637
database OvOOOO: win: 12564 draw: 718760 loss: 5443691
database OvXOOO: win: 27136 draw: 1276297 loss: 26329227
database OvXXOO: win: 22813 draw: 1201453 loss: 45031724
database OvXXXO: win: 7803 draw: 588947 loss: 33735810
database OvXXXX: win: 766 draw: 118354 loss: 9415300
database XOOOvO: win: 27628850 draw: 3809 loss: 1
database XOOOvX: win: 28834540 draw: 1844239 loss: 1
database XOOvOO: win: 32911442 draw: 8640786 loss: 6012
database XOOvXO: win: 23053969 draw: 68820741 loss: 637270
database XOOvXX: win: 3429703 draw: 47263184 loss: 676233
database XOvOOO: win: 14218675 draw: 13298877 loss: 115108
database XOvXOO: win: 14695544 draw: 76486819 loss: 1329617
database XOvXXO: win: 5501009 draw: 94645036 loss: 2851635
database XOvXXX: win: 677427 draw: 35700282 loss: 1759971
database XXOOvO: win: 46255295 draw: 693 loss: 2
database XXOOvX: win: 50440708 draw: 928409 loss: 3
database XXOvOO: win: 41627171 draw: 4627486 loss: 1333
database XXOvXO: win: 38501527 draw: 64283329 loss: 212824
database XXOvXX: win: 6861237 draw: 50133450 loss: 211833
database XXXOvO: win: 34332560 draw: 0 loss: 0
database XXXOvX: win: 37912652 draw: 225028 loss: 0
database XXXXvO: win: 9534420 draw: 0 loss: 0
database XXXXvX: win: 10573242 draw: 20558 loss: 0
database XXXvOO: win: 16163471 draw: 959562 loss: 7
database XXXvXO: win: 18422223 draw: 19702916 loss: 12541
database XXXvXX: win: 3721724 draw: 17453342 loss: 12534
database XXvOOO: win: 11410120 draw: 3926891 loss: 2379
database XXvXOO: win: 14399093 draw: 36836772 loss: 133255
database XXvXXO: win: 5828061 draw: 51075655 loss: 302804
database XXvXXX: win: 734708 draw: 20279792 loss: 173100
database XvOOOO: win: 880270 draw: 4593382 loss: 1380118
database XvXOOO: win: 2201104 draw: 15643420 loss: 12834256
database XvXXOO: win: 1926319 draw: 23685363 loss: 25757438
database XvXXXO: win: 682391 draw: 16664636 loss: 20790653
database XvXXXX: win: 87242 draw: 4391556 loss: 6115002
=================
Compressed file sizes:
08/18/98 11:26 102,478 OOOOvO.cpr
08/18/98 13:55 926,123 OOOOvX.cpr
08/18/98 12:29 1,111,011 OOOvOO.cpr
08/18/98 15:10 1,838,556 OOOvXO.cpr
08/18/98 19:11 1,005,367 OOOvXX.cpr
08/18/98 13:25 943,757 OOvOOO.cpr
08/18/98 17:25 2,300,897 OOvXOO.cpr
08/18/98 20:17 2,102,270 OOvXXO.cpr
08/18/98 22:28 715,710 OOvXXX.cpr
08/18/98 13:49 384,439 OvOOOO.cpr
08/18/98 18:49 291,240 OvXOOO.cpr
08/18/98 21:53 271,182 OvXXOO.cpr
08/18/98 22:55 140,775 OvXXXO.cpr
08/18/98 23:21 31,508 OvXXXX.cpr
08/18/98 11:33 96,010 XOOOvO.cpr
08/18/98 14:03 1,598,227 XOOOvX.cpr
08/18/98 12:40 1,623,319 XOOvOO.cpr
08/18/98 15:36 4,438,023 XOOvXO.cpr
08/18/98 19:26 1,218,583 XOOvXX.cpr
08/18/98 13:34 1,305,895 XOvOOO.cpr
08/18/98 17:55 2,087,565 XOvXOO.cpr
08/18/98 20:50 2,173,717 XOvXXO.cpr
08/18/98 22:40 1,120,920 XOvXXX.cpr
08/18/98 11:50 142,178 XXOOvO.cpr
08/18/98 14:24 1,159,143 XXOOvX.cpr
08/18/98 13:01 1,252,369 XXOvOO.cpr
08/18/98 16:25 6,779,380 XXOvXO.cpr
08/18/98 19:53 1,629,654 XXOvXX.cpr
08/18/98 12:11 102,616 XXXOvO.cpr
08/18/98 14:48 420,087 XXXOvX.cpr
08/18/98 12:24 27,937 XXXXvO.cpr
08/18/98 15:02 64,147 XXXXvX.cpr
08/18/98 13:18 273,072 XXXvOO.cpr
08/18/98 17:06 2,707,992 XXXvXO.cpr
08/18/98 11:06 701,054 XXXvXX.cpr
08/18/98 13:44 655,089 XXvOOO.cpr
08/18/98 18:31 1,983,928 XXvXOO.cpr
08/18/98 21:29 964,488 XXvXXO.cpr
08/18/98 11:18 141,643 XXvXXX.cpr
08/18/98 13:52 560,961 XvOOOO.cpr
08/18/98 19:01 2,353,517 XvXOOO.cpr
08/18/98 22:13 1,474,560 XvXXOO.cpr
08/18/98 23:11 321,272 XvXXXO.cpr
08/18/98 23:25 34,366 XvXXXX.cpr
pc...@nos.pam.co.uk
>Harm,
>Perhaps it will be possible to compare your statistics of endgames
>databases with mine (4 pcs statistics was posted some time ago and some 5
>pcs statistics will be available REAL SOON NOW). By comparing the results
>calculated in two different ways, we can both raise our confidence in the
>correctness of the databases.
>Could you publish some statistics of the 5 piece endgames databases.
>Number of positions possible and win-draw-loss for both sides, the maximum
>distance, the compressed size per database.
>You talk about databases. Does this mean you have several physical
>separate files? During the alpha-beta search DAM 2.2 will need endgame
>information which will be scattered over several files and 'at random'
>positions within the (compressed) files. How will you manage these lookups
>(efficiently)? I suppose you can't preload everything in RAM.
Chinook uses W/D/L compressed representation (1.5 bits/pos)
which is then subjected to a sort of "Run length" compression (RLC) -
because you often get very long "runs" of results all
the same. The amount of compression achieved can be
amazing - the English Checkers 5 piece database, with
150 million positions compresses down to just over a meg
or so. Thats effectively around 100 positions stored per byte!
(See the Chinook WWW site for this DB with sample source..)
Once compressed, it spools into RAM nicely while searching..
Such compression is no use on full "Dist to win" type databases
- although I did have the idea of "rounding up" the DTW score -
ie, if a long run has *approx* similar DTW, store the average
& the run length - ie - "the next 30 positions have an av White DTW of
12 moves, the next 4 positions have an av DTW of 22 moves, etc..
Anyone care to experiment?
>I am considering chopping the files in fixed size chunks and storing them
>in a huge database and let the database do all the dirty work on caching.
>Whether or not I use compression on the win/draw/loss information and/or
>the distance to winn/loss, I haven't decided yet. Any suggestions?
Store 2 versions - RLC-WDL compressed for searches, full DTW/DTC
for instant lookup..
And send me a copy.. :-)
Seriously maybe we should start to make a "pool" of
PD checker resources on the web - I uploaded a
few bits and pieces to the "onenet" chess site.
For example - Al Lyman typed in 70,000 midgame pos
into Cornell a long time back, and I wrote a
little prog to convert that to standard "DPD" format,
and put both source & DPD file at:
http://chess.onenet.net/chess/DOS/Win3/checkers.zip /txt
Its an FTP site (ftp://chess.onenet.net) if anyone wants to
upload to its "upload" directory..
A long time back the 10x10 4 piece DB was there..
>There is another problem which i haven't quite solved: finding the exact
>value in the databases may take a lot of time (if disk-access is
>necessary), in some cases it isn't worth investing that much time, an
>quick-and-dirty heuristic value will do the job. How to balance the
>quality of the evaluation and the time invested?
I made the computer not try for DB looks near the end of
the search, but a few ply before.. A tunable factor in SAGE..
Jonathan Schaeffer
>I have included the 5 piece statistics at the bottom of this
>article. I don't have the maximum distance though.
>Jonathan Schaeffer has also published 10x10 database statistics,
>see DejaNews article http://x8.dejanews.com/getdoc.xp?AN=159647765
As I recall, that article had an error in one of the database counts.
It was corrected in a later posting.
>Having the distance to win/loss is expensive.
>My 4-piece databases include the distance to win/loss, they are 20 MB
>compressed. The new 5-piece files with win/draw/loss are only 49 MB,
>with each file containing its own index table.
Here are the sizes of my 2 through 5 piece databases. The total is roughly:
data: 35 MB
index files: 1 MB
1 -r-------- 1 jonathan jonathan 378 Apr 15 1996 DB2
4 -r-------- 1 jonathan jonathan 3530 Apr 15 1996 DB2.idx
27 -r-------- 1 jonathan jonathan 26812 Apr 15 1996 DB3
16 -r-------- 1 jonathan jonathan 15522 Apr 15 1996 DB3.idx
1320 -r-------- 1 jonathan jonathan 1350902 Apr 15 1996 DB4
60 -r-------- 1 jonathan jonathan 60453 Apr 15 1996 DB4.idx
12001 -r-------- 1 jonathan jonathan 12288350 Apr 15 1996 DB5.32
212 -r-------- 1 jonathan jonathan 216132 Apr 15 1996 DB5.32.idx
5953 -rw------- 1 jonathan jonathan 6095196 Apr 15 1996 DB5.41
117 -rw------- 1 jonathan jonathan 119099 Apr 15 1996 DB5.41.idx
15149 -rw------- 1 jonathan jonathan 15512452 Apr 15 1996 DB5
293 -rw------- 1 jonathan jonathan 299817 Apr 15 1996 DB5.idx
I will work on mking this public domain in the next few weeks.
As to the 6-piece databases... I have everything ready to roll but do
not have the time or initiative to do them. Anyone out there with a lot
of idle machines?
Bert van Oortmarssen
Harm Jetten wrote in message
<35f566b0...@news.xs4all.nl>...
>Having the distance to win/loss is expensive.
>My 4-piece databases include the distance to win/loss, they
are 20 MB
>compressed. The new 5-piece files with win/draw/loss are
only 49 MB,
>with each file containing its own index table.
>I do use the trick of excluding capture positions in those
files,
>replacing their values with the "dominant" value, a la
Chinook.
>That improves the compression ratio enormously. I don't
exclude
>capture threat positions, I might try that later if I need
still better
>compression.
>Before accessing the databases, capture positions first
have to be played
>out by the search routine, I let the quiescence code take
care of that.
>
Hi Harm (and Ron and Gijsbert and all others who read this
group).
I think Bunzo was the first program to use the complete 4
piece endgame information, I think the total size of the
files (including also WWWWB) is around 10 Mb (this is the
size in which the files are 'ready' to be used), and include
depth information. It would be no problem these days to
reserve this amount of memory for the endgame databases, but
at the time I wrote it I only had 4 Mb of memory available
(so in fact, the current version of Bunzo, which is
unchanged for at least 2-3 years, still does not reserve
this memory. But it would be very easy to change that).
The trick to reduce the size (at least what I use) is what I
call 'double bitvectors' e.g. a bitvector that denotes
winnable positions, and also a bitvector of this bitvector
and a list of bytes that are different to the default (all
one or all zero).
I remember one game (from the computer tournaments) where
Bunzo found a real neat way to win, by consulting the
endgame database. Another (embarrassing) moment came when I
lost a game due to a misinterpretation of the database
(single opposition on the main diagonal in the WB endgame
... I forgot to swap colours, oops ...).
My conclusion so far is that the 4-piece endgames do not
make a big difference, maybe a quicker way to win (or it
takes longer to loose ...). [But this conclusion is only
drawn from playing against other computers, maybe against
human players it has more importance].
Bert
Ron van Bemmelen
Thank you for publishing the 5 pieces endgames statistics. I compared your
results with Jonathan Schaeffer's. I came across some minor but intriguing
differences. The differences are listed below
LOSS
-- HJ -- -- JS -- DIFF
1 king vs 4 man *) 886489 886306 + 183
1 king vs 3 man + 1 king 2201105 2199700 + 1405
1 king vs 2 man + 2 kings 1926332 1924149 + 2183
1 king vs 1 man + 3 kings 682391 681528 + 863
1 king vs 4 kings 87242 87330 - 88
(best viewed with a non-proprtional font)
*) I have added the winn/draw/loss figures of OOOOvX and XvOOOO to
calculate the '1 king vs 4 man' statistics.
The WINN statistics do match as do the number of positions. The
differences are mis-classifications between LOSSES and DRAWS. This may be
caused by differences in the handling of illegal and/or unreachable
positions. Any suggestions?
> Win32 has a method of mapping a view of a file to virtual memory,
> where the user gets a pointer and can do random access as if it were a
> regular array. The kernel arranges all the housekeeping, paging into
> physical RAM etc. Very neat, works on both NT and 95/98. (The API calls are:
> CreateFile(), CreateFileMapping(), MapViewOfFile()).
Very neat, indeed.
> I do use the trick of excluding capture positions in those files,
> replacing their values with the "dominant" value, a la Chinook.
Boards with a capture: Instead of storing the initial value in the array
winn-draw-loss at index position board-to-linear-index, you store a 'fake'
value. This fake value is well choosen to optimize compressing. This fake
value is set equal to the overall outcome of this endgame. For example
OvOOOO loss and XXXvXX draw. Did I it right?
Ron.
Ron van Bemmelen
I didn't get the point with respect to the heuristic which decides between
- wanting an exact value (consult the database and doing disk-access)
- having a quick-and-dirty value (because this variation is a dead end)
The value of the best move (according to alpha-beta) is a backup-value of
the evaluation done at depth=0. The evaluation at intermediate plies may
guide the search process (move-order-sorting, null move,...) but don't
come into play when the best move is to be picked. Your heuristic will
never allow the evaluation at depth=0 to search the database.
Ron.
Harm Jetten
I hadn't realized that there were differences between the two.
Just now I checked the smaller databases generated by the same
program (DragonDraughts), and they do agree completely with
Jonathan's numbers. See statistics below.
Yes, it would be interesting to know why those 5-piece positions
are different.
>Boards with a capture: Instead of storing the initial value in the array
>winn-draw-loss at index position board-to-linear-index, you store a 'fake'
>value. This fake value is well choosen to optimize compressing. This fake
>value is set equal to the overall outcome of this endgame. For example
>OvOOOO loss and XXXvXX draw. Did I it right?
Yes, that's it exactly.
Harm.
==========
database XvX: win: 424 draw: 2024 loss: 2
1100 OK
database XvO: win: 1924 draw: 281 loss: 0
database OvX: win: 121 draw: 574 loss: 1510
1001 3434 121 855 OK (just under the wrong columns)
database OvO: win: 736 draw: 799 loss: 450
0011 OK
==========
database XXvX: win: 19398 draw: 39402 loss: 0
database XvXX: win: 3240 draw: 54988 loss: 572
2100 19970 3240 94390 OK
database XXvO: win: 51041 draw: 1879 loss: 0
database OvXX: win: 245 draw: 8645 loss: 44030
2001 95071 245 10524 OK
database XOvX: win: 24373 draw: 81465 loss: 2
database XvXO: win: 16367 draw: 88967 loss: 506
1110 24879 16369 170432 OK
database XOvO: win: 85503 draw: 9776 loss: 1
database OvXO: win: 1745 draw: 24414 loss: 69121
1011 154624 1746 34190 OK
database OOvX: win: 5269 draw: 30939 loss: 11312
database XvOO: win: 26807 draw: 20636 loss: 77
0120 5346 38119 51575 OK
database OOvO: win: 28464 draw: 13754 loss: 572
database OvOO: win: 3343 draw: 19298 loss: 20149
0021 48613 3915 33052 OK
============
database XXvXX: win: 146610 draw: 1231758 loss: 3432
2200 OK
database XXvXO: win: 791742 draw: 1692074 loss: 3424
database XOvXX: win: 147277 draw: 2310213 loss: 29750
2101 821492 150701 4002287 OK
database XXvOO: win: 965081 draw: 151638 loss: 1
database OOvXX: win: 11259 draw: 441660 loss: 663801
2002 1628882 12260 593298 OK
database XOvXO: win: 882645 draw: 3568953 loss: 26562
1111 OK
database XOvOO: win: 1455811 draw: 554042 loss: 1277
database OOvXO: win: 124309 draw: 1016052 loss: 870769
1012 2326580 125586 1570094 OK
database OOvOO: win: 276206 draw: 530815 loss: 96419
0022 OK
database XXXvX: win: 486444 draw: 434756 loss: 0
database XvXXX: win: 16812 draw: 863802 loss: 40586
3100 527030 16812 1298558 OK
database XXXvO: win: 821215 draw: 7865 loss: 0
database OvXXX: win: 460 draw: 90091 loss: 738529
3001 1559744 460 97956 OK
database XXOvX: win: 1034406 draw: 1452834 loss: 0
database XvXXO: win: 122349 draw: 2302813 loss: 62078
2110 1096484 122349 3755647 OK
database XXOvO: win: 2182315 draw: 56765 loss: 0
database OvXXO: win: 3864 draw: 323718 loss: 1911498
2011 4093813 3864 380483 OK
database XOOvX: win: 665906 draw: 1567532 loss: 2
database XvXOO: win: 252883 draw: 1951696 loss: 28861
1120 694767 252885 3519228 OK
database XOOvO: win: 1857837 draw: 153291 loss: 2
database OvXOO: win: 8518 draw: 449923 loss: 1552689
1021 3410526 8520 603214 OK
database OOOvX: win: 116381 draw: 537278 loss: 13271
database XvOOO: win: 176586 draw: 486360 loss: 3984
0130 120365 189857 1023638 OK
database OOOvO: win: 465316 draw: 135152 loss: 242
database OvOOO: win: 7801 draw: 231592 loss: 361317
0031 826633 8043 366744 OK
===========