Website founded by
Milan Velimirović
in 2006

0:05 UTC
ISC 2020



Remember me

Forgot your
Click here!
to create your account if you don't already have one.

Rating lists


MatPlus.Net Forum Internet and Computing EDIT: Nevermind. Old text: EGTB small filesize database creation proposal (not for end-user)
You can only view this page!
(1) Posted by Siegfried Hornecker [Friday, Nov 13, 2015 14:50]; edited by Siegfried Hornecker [15-11-13]

EDIT: Nevermind. Old text: EGTB small filesize database creation proposal (not for end-user)

EDIT: Disregard this, I just found that 3 piece EGTB are already only 62 KiB, so my proposal is completely useless.

I want to propose on a new format on creation of endgame tablebases, only for archival purposes, not for end use.

- Small comprehensive size.
- Potentially decipherable without knowing how it was created.

- Bigger single file size, as there will be only one file per number of pieces.
- Every number of pieces needs an own algorithm.
- Whole file must be loaded on the fly.
- Space is wasted for impossible positions, including those where pieces overlap each other.
- Long loading times to be expected.
- Either no discrimination of castling and en passant cases, or discrimination in every position, regardless of if it is possible or not.
- No discrimination of draw, immediate checkmate and illegal position. (can be remedied)

I propose a format that works as following. Every position is created from a mathematical pattern. It starts by taking position X and inserting a white king on a8, then on b8, etc. Then the same is repeated for the queen, the rook, etc., and finally for each black piece until each position is evaluated.
The result then is written into a database. The database may use any arbitrary format, not only binary, but the format has to be specified in a separate file.
As an example for what could be 3 piece endgames, each 6 bit could be used to determine the state of an endgame, making a maximum of 63 moves possible per side. In the case of 0, the endgame would be drawn, impossible (overlapping pieces) or already checkmate. In the case of any other number, that number would name the number of moves to checkmate, first for White, then for Black to move. It also would be possible to give all 1s for impossible or checkmate positions, so essentially FFFF on a 8 bit base.

The issue is that the algorithm builds always on previous positions, making it on one hand small, but on the other hand it is not possible to load a position without determining it from going through all previous positions. I provide a handmade database for one piece, written on a 1 bit algorithm, here.


This is a line of 256 1s, when a masterfile is set that declares sets of two 1s as illegal positions, as well as the length of an evaluation as 1 bit. The file for 2 pieces would be 65,536 bit or 8,192 byte long and the last set that can be built at only 1 bit length per position, regarding 0 as draw and 1 as illegal. The file for 3 pieces would then be obviously taking all the previous positions into account, stretch it to 6 bit per position and evaluate at this base for a total of 100,663,296 bit or 12,582,912 byte.
The decryption file itself also would not need to be big as it holds only few instructions, enabling results of all positions of up to 3 pieces to be held in less than 13 MB of space, including illegal ones. Naturally, by the algorithm, a huge part - the majority - of the positions will always be illegal, but I believe this to be still a minor tradeoff in regards to the final file size. For example the very first position in the 2 pieces set would have wKa8 wKa8, making it illegal.
It might be possible to save more space by only saving a position and an indication where it would be in a complete set, provided it is legal, but that would have to be tested.

Again, this will be very slow on real-time use, and can only be for purposes of a decipherable algorithm for long time preservation, such as in time capsules or interstellar communication.

[EDIT2: Yes, I noticed the error I made above, but even so, the tables now created are much smaller than my proposal.]
(Read Only)pid=13997

No more posts

MatPlus.Net Forum Internet and Computing EDIT: Nevermind. Old text: EGTB small filesize database creation proposal (not for end-user)