OpenChess

I think The King was using FEG bases, which are distance-to-mate.

Fruit (or actually Toga I think) uses Scorpio bitbases by Daniel Shawul. They essentially flatten the Nalimov format down to win-loss-draw info, and have some "good SEE" capture logic to make the data more redundant (for compression purposes). My recollection is that the one-sided lot is about 200-300MB (you only need 1/2 the data, as search can perform 1 ply and get the other). I think the Shredderbases (441MB or 157MB in the 1/2 data format) are superior. One difference is that Scorpio bases unpack 8K blocks into a memory cache (just like Nalimov), while Shredderbases (I presume) use something more like run-length encoding. This means the Shredderbases can sit in memory, while the Scorpio bases can't do this so easily (it would be many gigabytes). The RobboTripleBases are like the Shredderbases I think. It seems that Gaviota can also flatten the format to win-loss-draw (not sure if this requires code modification), or it can also do "on-the-fly" bitbase construction according to the info. There are occasionally webpages that list various schemes and formats, but these seem to go out-of-date as time passes. Maybe I can try to prepare a list of what systems there are, and the technical aspects of them (if I can determine this). Nalimov has been "the standard" for a decade, though it is not w/o its faults.

Thanks for the update on the tablebases.

Formats do need to be updated from time to time. It would be great if the major chess programmers could come up with some standard way of doing this, so when people want to run their favorite engine, it wouldn't be necessary to have yet another type of EGTB's.

As we look forward to having a 7 man EGTB in the future, the size of the data becomes a more important factor, surely.

Formats do need to be updated from time to time

The recent 3TB (or 2.72 depending on convention) hard drives are an example. http://www.digitalartsonline.co.uk/news/?newsID=3244927 --- see also http://www.legitreviews.com/article/1442/2/ for a bit of background.

"The previous 2.19TB capacity ceiling was set about 30 years ago when a decision was made to limit the logical block address (LBA) range on a hard drive. The LBA specifies where blocks of data are stored on a hard drive.

"[...] industry leaders decided in the early 1980s the to limit the LBA range to 16 bits per drive sector because "they never thought we'd go beyond a 2.1TB drive." Software and hardware manufacturers now need to adjust everything from the operating system to the basic input/output system (BIOS) to be able to read larger LBAs [...]"