CCRL Discussion Board

I'll try that new code of yours Muller, great! Currently my head is spinning with this reverse algorithm. I'll have a small time out

Hmm... So I have to store this bitbase too (at least in endgames where black does have more than just a king). I am hesitant to store this in the dtm-byte, because in 6 men endgames the remaining 7 bits are not enough to store dtm's that are >127. Maybe I have to make the datastructure for 3,4,5 men...

Getting confused...
How can I generate DTM=0 entries in a wtm-file?? they do not exist! So how can you store any DTM then?

It seems you are generating wins for both sides at the same time, and do not distinguish wins for black and wins for white.

That I discovered today, yes.
So it should be easier to generate 2 files, one for wtm and one for btm? I still have to learn a lot, but I'll manage. It costs time.

I just built my first egtb with black having a piece to. wtm en btm positions are stored in 1 file. Up until now generating seemed good (still with my slow forward moving retrograde analasys). With a bare black king the algorithm works but now it generates helpmates. Let's take this position in KQKQ...

Thanks! The tricky thing is this: Of most positons there are 8 versions (related by rotation or reflection), 1 RP, and 7 VP. We could say the entire set of 8 is represented by the single RP in the TB. If the RP has DTM=2, the 7 VPs also have DTM=2. Every parent of every position in the set will have...

Ok about this symmetry. I want to ask a questions to see if I understand it: Let call a position this is in the egtb "RP" (Real Position). And a position that is not (so a position that has to be rotated and mirrored to do a probe) "VP" (Virtual Position) 1) I'm testing a RP wher...

I'll study on that again Mr. Muller.
I think I understand the algorithm, but there must be a diabolical bug in my code. I'll have to debug and debug again and again..
I'll think too about your remark about the "tricky" unique triangle in another post.

You don't have to loop through all positions again every depth. Instead you can just do an unmove from the critical positions. eg to get all positions where black is mated in n+1 you take all wtm (white wins in n) positions and do one unmove. Ok still having problems here. Assume I have this positi...

I know that last one, but having all kinds of problems writing my code.

What are the tbs-files?

I would like to verify if my tablebases are valid. The best would be taking another tablebase, probing all positions and checking the result with my own tablebase.
Is there anyone who knows how to do that? Or maybe there is someone who has some code?

Ok, I'm relatively new to tablebases. What is WDL EGT? What is DTZ? DTC = Distance To Conversion I know that. I am writing a DTM base as far as I know :) I will try to write a UnMove() function, which will not be very easy. But I cannot imagine how this saves time: what's the difference between acce...

I really do not understand how to generate 5-men tables in a few minutes. my KQN-K (4 pieces) takes 14 minutes and everything is done in-memory!

Sounds like magic, Codeman... I'll test it. But I will have to write a GenerateMovesReverse(), hmm...

Does anyone has some tips or tricks to improve the generation speed of tablebases? The method I'm using right now is the most simple: Loop through all positions and find DTM=0, then loop again and find DTM=1 etc. This is all done in memory for 3,4,5 pieces, but will not be possible for 6 pieces, so ...

My generator is written with Delphi (7). No problems there

Okidoki, I got it working! My files are much smaller now than Nalimov's! I'll make a list here soon for comparison

Ok, good news. The precomputed file for 4 same pieces is just 2,5 MB so this saves me a lot of puzzling. To be continued...

I'll study on that :) I precalculate the factorials for speed before generating or probing. I need the reverse function to be able to delete invalid positions and insert them on the fly when probing/decompressing. I'm thinking now to create a few files with precomputed "same-men" indices. ...

for groups the index is harder to calculate you have to order the pieces first. for you 2 queen example: q1 = queen on the higher square, q2 = queen on the lower square q1 * (q1-1)/ 2 + q2 if you now want to add a 3rd queen it would look like this: (again q1 > q2 > q3) q1 * (q1-1) (q1-2) / 3! + q2 ...

Simple and smart, thanks!
I'll have to check if the Decode procedure isn't too timeconsuming, probably not.

After all the bitpacking was not succesful. It "confuses" the bytes so normal datacompression should be enough.
My KRQK file is now 663 KB. Coming closer to Nalimov (500)
KQQK is 379 KB, Nalimovs about 320 KB
I think I need one more last space-optimization and then I will be satisfied.

Hmmm... I can't think of anything else than a sort of RunLength pre-compression for that idea of yours. Is that the way you should handle it, Koistinen?

That seems like a good idea. I will have a try at that.

The code needs some cleanup, but I'm certainly planning to put everything online somewhere as freeware, when it's finished (I guess somewhere within a half year)

Ok, thanks to your great answers in my other posts I got my tablebases working! A short description: -Positions with wtm and btm are stored in one file. -duplicate squares are stored (in case of non-same pieces), but i think this is not very much -use of unique triangle -use of precomputed legal kin...