CCRL Discussion Board

I see what you mean now with regards to reducing size -- any positions which are "forcing" need not be stored/indexed. If I'm understanding that correctly, but then it smells to me like complicated bug prone code for unknown amount of space saving... Definitely something to try but at a la...

What you are trying to do, is encode positions after each capture, i.e. after "sub-plies". As a result, you need to encode the piece-that-is-moving. This is very very suboptimal. Not quite. While it's true that in my engine I've broken down single-ply captures that involve multiple captur...

For example, when I have this position:
7k/8/8/8/8/8/8/K7 b - - 0 1

I have a factor of 10 for the white king, but I still have a factor of 64-1 for the black king, correct?

Yes the 1 piece scenario is clear for me, as I mentioned before.

What's not clear for me is how it works with a 2nd piece. For example, how do you introduce the black king while having the space saving from symmetry?

Actually just thinking about it the 65 factor should be reduced to n where n is the number of enemy pieces... So I think I can already reduce the size to 6 MB, and to 3 MB if I only need one side... And that's without symmetry. (And for 4 pieces it looks like it'll be ~878MB...) I still don't unders...

Currently my tablebase is indexed using the side-to-move information which is probably not required? And also the last piece moved square - information necessary for move generator because if this last piece can be captured, then it must be captured. The size is calculated like this (the 65 factor i...

So now that I have my very first endgame generator working in the most primitive way possible (for a turkish checkers variant) I would like to learn how to reduce the size. For example, my current 3-piece egtb weighs in at around 200MB (5mb compressed) which, comparing to chess egtb, is on the order...

Of course next step would be to make sure the database makes full sense, and then (or at the same time) to find the longest wins, and funky positions, and that sort of stuff, in order to study the game itself! :D If anybody is interested, you can play the game here: http://qw.quakephil.com/giventake...

I got most of this done now (the endgame without backwards moves) mostly by trial and error :) I've also written a pretty cool interface to it (inspired by the k4it nalimov browser ) Thank's for the insights here! My code is pretty gross and slow. If anyone wants, I can clean it up and post it here....

Fun fact - Matryoshkas (I've never heard them called "russian dolls" before, or "<any kind of nationality> dolls" for that matter) originated in Japan

I see; the problem with my case is that it is difficult (well, non-trivial) to generate reverse moves. So while I am generating the moves forwards, I am doing the big picture backwards, because first I'm calculating the simplest positions (K-K) and then the positions backwards from that (such as K-K...

Another question I have is, in general, what is endgame tablebase verification? What does it mean to verify or not to verify a tablebase? How does automatic verification work, in a perfect world? I'm guessing it is some kind of "checksum" tes... If so, what's the sum? Or perhaps independen...

I find this service useful: http://www.k4it.de/index.php?topic=egtb&lang=en

But as you say, you need javascript access. I'm not sure what that site offers besides FEN input..

I emailed Kirill about an endgame question concerning a game which is not chess, but a boardgame nontheless. Actually, it is a variant of turkish checkers. Anyway, he suggest I post here, so here I am :) My main intent here is to pool from the collective experience you have in creating endgame solve...