CCRL Discussion Board

A 32bit operating system can't address more than 4GB. So it would be possible that the generation takes 4 byte per position and this just exceeded this limitation. 4 bytes would make sense, as Nalimovs egtb are DTM, which have to store values > 256 for 6men. Thus it probably reserves 2 bytes per pos...

I don't know, how much memory is required per position, but

1301488080 positions / byte per position = 1.21 gb

so you have to check whether you have enough ram for this operation

A little improvement to this would be to, instead of using one 64 bit key for the position + some bytes for the move one key which contains 32 bit of the old position and 32 bit of the new position. Thus you save some space, which might be relevant for aligning purposes, without increasing the risk ...

Quoting kirill's great site about tablebases: http://kirill-kryukov.com/chess/tablebases-online/

to the right of all links you find a link to the tbs files

As well you can generate some stats and compare it to nalimov's *.tbs files

Or you can build your own verifier, that goes through all positions and test whether the value is fine by checking the values of the child-nodes.

This should work well for endgame with <= 6 pieces .. but for anything bigger, you would need another approach.

Ok, I'm relatively new to tablebases. What is WDL EGT? What is DTZ? DTC = Distance To Conversion I know that. WinDrawLoss ... Tablebases which have 2 bit per position. (win, draw, loss, illegal) Distance to Zero ... Same as DTC, only that pawnmoves (=irreversible as well) are used as zeroing moves ...

Another option is to use Bitbases. They will take about 2GB-ram to generate a 6men pawnless EGTB (pawnfull are even cheaper). One option to save you from generating the moves every time again is to save the movecount once in a byte variable for each index. And everytime you get to the node again you...

notnale wrote:If I were trying to write my own generator, what would the easiest/most efficient language be?

For EGTB generators you need to write code that compiles as fast as possible and you need good access to memory management.
I would suggest C++

q1 * (q1-1) (q1-2) (q1-3) / 4! + q2 * (q2-1) (q2-2) / 3! + q3 * (q3-1)/ 2! + q4 Thats very expensive! And you don't need it at all. Where do you want to use that? I cant think of any way other than looping at the moment: Loop i = 63 to 0 if (index < i * (i-1) (i-2) (i-3) / 4!) { q1 = i + 1; break; ...

One more index optimization Nalimov uses is that it doesn't index unblockable checks from the stm eg: KRK, white to move and black King on e4. instead of having 63 left squares for the white rook, what he says is that no matter where the other pieces are standing, the rook may never be on d4,f4,e3,e...

You have to make different groups and for each find the max-index... 1) WK & BK ... with an index for pawn-less you get 462 index numbers 2) if you have any pawns index them right after the kings, because they will reduce the possible number of squares for all following pieces, but not the other...

I never understood the motive for people doing damage through corrupting files (like in this case egtb-files)

KBNKNN.TBS has the same issue. There are also no "Broken Positions" for "Black to Move" listed. Am I right, that "Broken Positions" are positions, where - for example - both Kings are in check? It could be, that the counter result with overflow was exactly was 0. So we...

There are two sides to indexing. On the one hand, the better you index the smaller will be the final file you get (and the space requirements during generation). On the other hand, better indexing also means that it takes more time to load/generate the positions. When using special index optimizatio...

What do you think of this: Keep the black king fixed to the triangle and when loading a certain slice to RAM, additionally load the black king on d1,d2,d3,d4,d5,e5,f5,f4,g4,g3,h3,h2 (all squares the black king can go to from the triangle) with all the white static pieces mirrored accordingly. The si...

Today I encountered a little difficulty, when trying to implement the symmetry optimization to my new bitbase-generator code, which uses the idea by h.g.muller that only one white piece is kept in ram at once. I wanted to use the system working in Nalimov's code, where the black king is always restr...

Translation: Mate in 530 Moves - Who can solve it? White: Kd2/Qh1/Rh4/Be3/Nb6/Nh2/c6/e6 (8) Black : Ke5/Qg3/Re7/Rg7/Bb3/Nf6/Ng5/d7 (8) regards Lutz Neweklowsky Draisstr.1 76135 Karlsruhe mailto:lutz.neweklowsky@gmx.de --- and here is the solution of #530 , because it is not easy to understand : the ...

First of all: 6-men have 64G positions Because of the 8-fold symmetry this reduces to 8G positions. As for the (2+4)-men the memory requirement is just over the edge (1.7GB + 0.5GB > 2GB), trying to squeeze out a few broken positions might be worthwile here, as even a few percent of savings counts....

About kQQQkQQQ, I guess that (462*62*61*60*59*58*57)/(6*6) = 568 *10^9 positions. i guess that quite many are illegal? Tuhma The indexing I described here just avoids having the two kings standing next to each other and two pieces standing on the same square. As well as it takes advantage of the po...

Hello, I see that you are trying to make tbgenerator that would enable 7-men tablebase generation? Is so, then I would like to know how long would it take to generate one 7-men tablebase using your tbgenerator? Like KQQQKQQ or KRRPKRR ? I made some tests using feg and using it KQQQKQQ would take ab...

I did a kind of back-of-the-envelope calculation on what would be needed to build 6-men pawnless bitbases entirely in RAM. A pawnless 6-men has 8G positions. The idea would be to keep this in RAM as compressed data, and use my slice-by-slice algorithm for the generation, packing and unpacking the d...

*.tbs files are just for research and verification purposes and are not needed by the engines. You can open them in a texteditor and check, what type of endgame it is. Some of the larger Endgames are split into various files to avoid the size of one file exceeding a certain boundary. They should be ...

I would not recommend building the black wins and the white wins simultaneously. They need different access patterns, and their storage need just add. (The wtm positions need many states there.) Just build them separately. When the building is finished you no longer need to distinguish the lost pos...

I have just started experimenting with threads to do loading and calculating at the same time .. looks quite promising. Sub end-games with a captured piece are much smaller, and you would need them to 'seed' won positions with wtm, and non-lost positions with btm. If you are building DTC or DTZ, all...