CCRL Discussion Board

The uniqueness concept is similarly simple: The number of unique legal positions should count only one position out of all of its symmetrical equivalent variants. This includes swapping the side to move, and also diagonal symmetries and rotations of the board. What about swapping pieces of identica...

Interesting you did atomic. Did you publish any statistics for 3-5-men endings for that? It seems I never quite finished converting my old generator for pawnful endings to atomic. I've now implemented a new generator and have just generated the statistics for atomic 3-5 endings. Here they are. The ...

Ok, so what you propose (I think) is generating tables with correct, but incomplete, information. For WDL, you would store values W, D, L, >=D, <=D, unknown. By generating only the more reasonable subtables and/or successor P-slices, you will end up with only a small portion of incomplete informatio...

So you do get a fully correct DTZ for that. So KQKa4, KQKa5, KQKa6 and KQKa7 can all be completely calculated without having KQKa3 in DTZ (only in WDL), and without having KQKa2 (not even WDL, just a few wins) and KQKQ, KQKR, KQKB and KQKN not at all. But here you are relying on luck that you can o...

With such a metric you will avoid the behavior (to which the common public no doubt would take great offense) that the engine will start to sacrifice all the material it has in excess of the bare minimum as quickly as possible, then lets the opponent advance his pawns until they can barely be stopp...

(Anyway, if a coordinated 7-men generation effort is started, it would seem wise to go for DTZ and not DTM. Then only WDL files are required for the subtables.)

Most people interested in this project will already hold most if not all Nalimov 6men tables. It would save the whole project a lot of precious processing time and network bandwidth if a tool was built that can convert nalimov files to this new format. A simpler solution would be to let the generat...

Most people interested in this project will already hold most if not all Nalimov 6men tables. It would save the whole project a lot of precious processing time and network bandwidth if a tool was built that can convert nalimov files to this new format. A simpler solution would be to let the generat...

These files were created on a computer that was also busy doing other things (his program is SMP and it seems to have something equivalent to the Unix nice command since it yields when I have other apps needing resources): What CPU and how many cores? What does it produce? DTM or DTC/DTZ? I suppose...

I see you've found this forum before I did

I suppose broken includes positions wherein the side to move can capture the opponent's king.

I usually build a table together with all possible successor tables, (stored in the broken positions), as my generator is purely RAM based, and doesn't do any disk acces at all. So it has to start from scratch every time. Do you generate everything as one big table, or do you generate the smaller t...

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 l...

While it's true that in my engine I've broken down single-ply captures that involve multiple captures into sub-plies, in other words a1xa3xa5 is actually represented as 2 plys worth of moves: move a1xa3 (with same side to move) and then move a3xa5 (with next side to move). However, the tactical squ...

Then for three pieces its WWB + WBB + WBb + Wbb + WwB + wwB = 195 MB :(:( If you have WWB, you don't need WBB since you can simply change the color of all pieces and the side-to-move. Assuming W stands for white king, w stands for white pawn, I get: wwb: 2 x 24 x 47x46/2 (place b first, then ww) ww...

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. I'm not familiar with the rules of Turkish check...

Wow, I somehow totally missed that thread. Thanks for posting the link. I was actually wondering about these questions some days ago and was pleasantly surprised to see I had already looked into these issues about three years ago :). In particular, I am amazed that the idea of storing a rounded met...

Originally I thought this issue was not important, and that simplified move-counting DTC was sufficient (and more compact) than a perfect DTC in plies. However if we add a 50-move (or any N-move) rule into the picture, a real problem appears as the move-counting DTC can lead to error in recognizing...

szyzygy - do you have a source/reference for that neat formula for 'Q' which enumerates the positions of like men? I just noticed this old post in which guido gave the same formula. While I agree with guido that the inversion process is a more complicated and less fast, it is certainly a lot easier...

simaton wrote:How would you guys learn it?

I would look for a book in which the author explains the basic techniques and classifies the most important patterns.

I'm not aware of any such book or explanation for KQKR (but I never looked for one either).

If one could hold a list of facts along the lines: - the best DTM achievable is dm1 but takes dz1 plies in this phase - the next bet DTM achievable is dm2 and takes dz2 < dz1 plies in this phase etc. then all would be well, without a move-count, but that's a new kind of data-structure no-one has th...

While I have described a construction that, provided the two sides play SM50-/SM50+, gives a set of paths through the EGT that decrement DTM by 1 ply each time and take no longer than 100 plies in the phase, it's not obvious that the defender cannot 'bail out' and just play SZ50+. I would say SM50-...

szyzygy correctly raised an issue as to whether mb's DTM50 EGTs not only had the same wins and draws as the DTZ50 EGT but also avoided leading the winner into a 50-move draw-claim. I never claimed to be discussing mb's DTM50 tablebases (which actually seem not to exist). I was reacting to ernest, p...

Why is this forum getting more and more contaminated by this stupid 50-moves-rule?? Some reasons: - some people are absolutely convinced that tablebases should take into account the 50-move rule, because in our world the game of chess includes the 50-move rule. - some people find it interesting to ...

If a DTM50 EGT 'EM50' is properly constructed to meet both the draw-claim-avoidance and depth-minimaxing goals (for which we now have an algorithm), then SM50- is the correct strategy to use on it. With a Nalimov-type table that stores for each position and side-to-move a single value, with SM50- c...