CCRL Discussion Board

This is very interesting work featuring two relatively new innovations: - multiple, ply-count-related, DTM50 depths per 'physical' position (pace e.p.), and - the use of the functional programming language HASKELL (and only Joe Hurd has used an FPL (HOL) on EGTs before). Yeah, I'm a bit of a functi...

Ok, I think I got it. Our ideas are different because my generator back propagates DTM when galen's (and also the one h.g. muller has in mind) back propagates DTZ (a good sign being that my generator and galen's one have totally different designs and up to now have produced results that match exact...

I don't see why slicing would slow things down. Basically it is just doing the same things in a different order. And the smaller your working set, the faster the program would typically run. Going to 4KB slices might seem unnecessary when you have 16GB RAM, but it means you can run from the L1 cach...

I would always slice by square. Why not use the extra reduction if you can? Well, if you don't need it, you don't need it. For instance, kpk takes maybe a megabyte; splitting it into 40 kb chunks would be pointless, and there is time overhead and code complexity associated with slicing. Splitting k...

Of course, memory is the real limitation. I could pretty much right now build arbitrary 6-man pawnless non-5v1 tables with the existing codebase, except for the tiny wrinkle that it would require a few hundred GB of RAM to do it. Maybe the solution to this problem is to write down the results of ea...

Thanks! The original position (from the Rybka forum, I think) was: 8/8/8/6kp/2p5/2N2K2/8/3N4 w - - 0 1 Someone complained that my tables did not score this as a win, whereas the Nalimov tables did. Of course the position is a draw by the 50-move rule. What is somewhat funny is that after 1.Ke3, the...

This position has mc=0 (max DTM50 positions in kqpkq have mc=0 but this is not always the case for other endings) and can be reached in 4 moves from the kppkp position Kc4 Pe4 Pe3 / Ka2 Ph5 which ought to be a mate in 141 and may well be the absolute DTM50 record for 5-men. I have now built complet...

Among the 9 endings that are directly influenced by the 50-move rule (knnkp, kqpkq, kbbkn, kbnkn, krbkr, kqrkq, krpkq, kbbkq, knnkq), the first 6 ones are already generated and the results are the following : For endings with direct (rather than inherited) 50-move rule influence, this list should a...

Hi syzygy! I've been trying out your generator. It's very nice. You clearly know the field quite well. (By contrast, I was largely winging it when making my generator.) I have one question for you, however, might be a real issue. Whenever I generate a table, I get output like this (e.g.): find optim...

My TBs are in a raw binary format that is easy to read so it should be immediate for you to build a code that checks them against yours. I would recommend kbbkb for a first try. This TB is small (6Mb packed) due to the extremely drawish nature of the ending, but has positions with multiple DTM50 va...

Hi Kronsteen, great to have you on this thread! First, the errors you pointed out: I rechecked those two positions against my tablebases, and they agree with your corrections. I clearly made a few off-by-one errors writing up the results. Thanks very much for your careful checking! And, I'm glad tha...

krpkq is complete. The deepest DTM50 (at zero count) is mate in 98, which is unique up to the horizontal flip symmetry: 8/8/1pk5/K7/8/8/1r6/4Q3 w One move is lost relative to DTM to avoid a 50-move draw after the first pawn push. However, if the counter is high enough (33-36), the record is mated in...

I'd like to see the DTM50-line for 8/8/8/4k2p/7N/2N2K2/8/8 b - - 0 5 I have this position as mated in 85, 87, 91, 95, 98, 101, 103, or 118, or draw, depending on the initial count. When it's zero, here is a mate in 85 line (not unique): 1. ... Kd4 2. Nd1 Kd3 3. Ne3 Kd4 4. Kf4 Kd3 5. Nef5 Kc4[1] 6. ...

Hi! Having built my own generator and tables, as noted in another thread, I have come to compare my results to yours. To all appearances, everything matches up, which I think is good confirmation for both of us. Here are my notes: knnkp: To be super-precise, I find it begins to strike at depth "...

Kirill Kryukov wrote:Can you verify your tables against Kronsteen's ones?

I've now gone through all the claims in Kronsteen's post, and verified them against my table as all correct, modulo a few nitpicks, which I'll post in the other thread.

Here's my current draft: http://galen.metapath.org/egtb50/ Some available tablebases attempt to incorporate R50 in various ways, but in my view none are satisfactory. The most common is to add a "DTZ50" metric, which counts down to an irreversible move. It's not quite right, however, as i...

Hi, thanks for the welcome! Can you verify your tables against Kronsteen's ones? I'll do this soon. Confirmation is a beautiful thing. Do you think you could compute all 6-piece tables using 64 GB or RAM? Many more of them, certainly, but all? I'm sure not. What enabled me to tackle any at all were ...

I've been working for a few months on building DTM50 tables, with up to six men. Since I was inspired by a thread here (which I cite!), and since this is probably an interested community, I'm posting a draft write-up of my results so far. I also see that in the interim another thread has been posted...