Nalimov tablebases format and generation

[tnarg]

Hi, I'm intressed in writing my own generater for Nalimov tablebases but there seems to be very little in the way of refenence. I'm currently reading throw a 5 man vertion of tbgen and finding it hard going. Can any one suggest any other generaters or documantation I can look at?

[Edmund]

A nice information resource is the CPW (also with many external references quoted):
http://chessprogramming.wikispaces.com/Endgame+Tablebases

Some more general information:
http://www.horizonchess.com/FAQ/Winboard/egtb.html

On Dann Corbit's server you will find a variety of useful papers on egtb generation:
http://cap.connx.com/chess-papers/

Besides Nalimov other open source egtb generators are:
Scorpio (http://sites.google.com/site/dshawul/home)
HGMs Egtb generator (http://home.hccnet.nl/h.g.muller/EGTB.html, http://home.hccnet.nl/h.g.muller/EGT7/7-men.html)
Robbobases

Furthermore there exists a dedicated EGTB Board:
http://kirill-kryukov.com/chess/discussion-board/viewforum.php?f=6

regards,
Edmund

[Dann Corbit]

The marvelous Gaviotta style tablebase generator is also available and it is not only open source, but with Berkeley style license it can be used with any project.
http://sites.google.com/site/gaviotachessengine/

Details:
http://sites.google.com/site/gaviotache ... blebases-1
Code:
http://sites.google.com/site/gaviotache ... e/download

[Edmund]

The marvelous Gaviotta style tablebase generator is also available and it is not only open source, but with Berkeley style license it can be used with any project.

Hello Dann, is the generation code already open source? I remember Miguel said that one day he will publish it, but so far I can only find probing, checking and compressing code online.

regards,
Edmund

[tnarg]

Mmmm lots of hard stuff in there. I think I'm going to just index the king postion (ie 462 for pawnless games and 1806 for pawn games) and then index every possable postion for the piece after that*. Once/if I got that work I can start trying to be clever and I would need to be because using 4 bytes per postion (2 colours to move*2 bytes) it works out to be 9.6TB for all 3v3 and 2v4 tables.

Thanks for all the info its been usfull but I need to start simple and get somthing working.

* so for a KQRKNB my full index would be 462*62*61*60*59 in size KQRKNN would be 1/2 the size and KNNNKB would be 1/6 the size.

[Miguel A. Ballicora]

The marvelous Gaviotta style tablebase generator is also available and it is not only open source, but with Berkeley style license it can be used with any project.

Hello Dann, is the generation code already open source? I remember Miguel said that one day he will publish it, but so far I can only find probing, checking and compressing code online.

regards,
Edmund

Correct, the generator it is not open yet but it will be. I need to separate it from the engine first, to offer it as a stand alone program and get the code a little bit cleaner. The toughest part of reorganizing the code is done, but I still need to make it separate. As soon as I finish the next version of the engine, I will be back to many of the pending EGTB things.

One of the toughest things of releasing open source code (for me) is that you have to release something that at least is not-a-complete-mess. It takes time. In the long run, it is good because it forces you to be organized, but... when this is a hobby...

Miguel

[Edmund]

Mmmm lots of hard stuff in there. I think I'm going to just index the king postion (ie 462 for pawnless games and 1806 for pawn games) and then index every possable postion for the piece after that*. Once/if I got that work I can start trying to be clever and I would need to be because using 4 bytes per postion (2 colours to move*2 bytes) it works out to be 9.6TB for all 3v3 and 2v4 tables.

Thanks for all the info its been usfull but I need to start simple and get somthing working.

* so for a KQRKNB my full index would be 462*62*61*60*59 in size KQRKNN would be 1/2 the size and KNNNKB would be 1/6 the size.

regarding the indexing: it is always a trade off between computing time spent and space saved (more complex algorithms take longer to compute and consume less harddrive space). what you have to consider though is that after generation you can compress your tb and broken positions are very well compressible. So it is really arguable whether or not features like "no pieces may stand on the same square" or "side to move king may not be left in undefendable check" make sense. I would rather just stick to the Index of the 2 Kings (462 for pawnless endgames) and n-like men.

Anyway, the more important aspects to decide on are which format you are going to use (dtm,dtc,dtz-50, bitbases) and what algorithm you are going to use for the generation. The final storing of the tables is not so much of a problem. The real challenge is the ram bottleneck during generation.

[H.G.Muller]

Even the peculiar King encoding in Nalimov format is quite detrimental to efficiency, IMO. I always use plain concatenation of the 6-bit square numbers, including Kings.