CCRL Discussion Board

byakuugan, please use the "code" tag to enclose your code, otherwise it loses indentation and becomes unreadable. You don't need any graphical interface at this stage. You can think about interface after you have a working generator. For the interface part, instead of asking questions on c...

Yes, with computation of this scale (and even with minichess) we have to be prepared for random crashes and data corrruption. I am willing to take my chances, as my computation benefits greatly from larger RAM, and one error every several month is something I can (try to) live with. Also, storage ca...

Hi John, Here is the current version. 64-bit Windows binary, command line, single threaded, you need at least 4 GB of RAM total. Pre-release test build, so it's incomplete and slow. Still it computed 3-to-9-piece DTM and WDL tables already. To build the 3-piece DTM database: 4x4c.exe -build DTM 3 To...

The only way to verify a WDL50 table will be by verifying a DTZ50 table and re-converting it to WDL50 twice and comparing the two copies. You can generate once and then exhaustively probe each WDL50 position against any verified DTZ >= 50 table. Can't you? It's almost the same thing, with a little ...

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

Allan, my computation is mostly limited by IO and therefore by memory size used for caching. Therefore a practical 32 GB box will be a huge step forward for me. (64 GB would be even better if I could afford it). Another big improvement for me would be upgrading my storage with some SSDs. The computa...

As I nearly said, Christoph Wirth generated DTC EGTs with depth in plies. [As usual, I said 'N Wirth' by mistake as I tend to have Nicklaus Wirth's name in my head.] So you won't be the first to measure depth in plies, KK, but you might be the first to measure depth in plies correctly. :D For the c...

While we are talking about boundaries ... Most people assume that the winner does the conversion into the next endgame. This is not always true: the loser can convert a Pawn, or be forced to capture. N Wirth, back in the 1990s, inherited a piece of code that assumed 'winner does all the conversions...

From my perspective on Bulldozer a bigger let down is the dual-channel memory controller. With the upcoming Sandy Bridge-E from Intel I'll be able to assemble a relatively cheap machine with 32 GB RAM (8 x 4 GB), or a more expensive one with 64 GB. With a desktop Bulldozer 32 GB build is much more e...

I changed DTX, DTC and DTZ from move-counting to ply-counting. This results in about 14% size increase of compressed tables, but allows to correctly implement the N-move rule. All DTX, DTC and DTZ tables will have to be recomputed. Fortunately DTM and WDL are not affected, also 1 byte per position s...

I'm now considering to redesign my solver a bit, to work around the imperfection that my DTX/DTC/DTZ tables can't be used with N-move rule. I'd have to either completely separate the DTx in plies from WDL information, or just store the DTx in plies. This probably also means upgrading from 1 byte to ...

Allan, it's very interesting for me to follow your thoughts and your experiments. I'm also very curious about the compression rates you can get when storing moves. Also how various heuristics affect the compactness. I appreciate when you post your results or ideas. Likely I'll build some Russian dol...

Kirill: My default is to view this as a big computation that's performed in full glory twice or thrice on highly specialized platforms. I can't get my head around terabytes for every man. Perhaps you think bigger than I do. I see an unconquered mountain, you see a tourist attraction. But I apprecia...

Kirill: I was perhaps being too subtle. By "plan" I meant planning on a psychological level. When I write code, I'm thinking almost exclusively about the 1% or 0.1% or 0.01% contingency, not what my code will do 99% of the time. Later, if you do end up debugging your code with a tracing t...

Programmers get sucked into visualizing the interior case by planning to debug their code; I never plan to do so (for a special value of studiously near-sighted). We also suck ourselves into this by writing if/else constructions without distinguishing between necessity (solely dictated by pre/post ...

Actually I was wrong to say that you don't benefit from verification in your scenario. Although verification won't help you with solving bugs, it may still catch some other bugs (IO, compression, hardware, etc). So I guess it's still a good idea to implement verification, even if your solver only ma...

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

guyhaw wrote:The DTM EGTs seems to compress by a factor of ~4, and the DTZ EGTs by a factor of ~8.

This is interesting. Nalimov's 6-piece DTM is closer to factor 3, as far as I understand. Can you be more specific, who's numbers are these, on what set of endgames, etc? I'm especially curious about the DTZ claim.

I found an hour over the weekend to compute the pawn slices of KPPP-KPP. Looks good to me. In my solver I allow pawns on the first rank (white on first, black on last), so the combinatorics becomes slightly more complicated. One question is what do you do with left-right symmetry. You could omit on...

The encoding of depth need not be aligned with the sign-bit of a notional integer of say 8 bits. It needs to cover 'draw', 'index unused' (aka 'broken' in Nalimov terminology), lost in 0-n1 and won in 1-n2. If (n1 + n2 + 3) > 64, Nalimov used a 16-bit integer. The choice of 8 bits or 16 was made by...

While we are talking about boundaries ... Most people assume that the winner does the conversion into the next endgame. This is not always true: the loser can convert a Pawn, or be forced to capture. N Wirth, back in the 1990s, inherited a piece of code that assumed 'winner does all the conversions...

Also, I'm wondering, has anyone thought about making an endgame solver (or perhaps a complete engine) for a generic variable size board game, given a rule file which can incorporate any kind of rules, from chess to checkers to fairy chess to this game? Of course it would not be as powerful or as fa...

What you call "wrong" is not what I said. My use case for WDL is: You start with correct WDL tables. Then you compute a DTZ (for instance) table. This DTZ table won't be used when building any other DTZ tables, so any errors in this DTZ tables won't pollute any other tables. This was my po...

Kirill, your points on independence and accuracy are good ones, though I would have guessed DTC were similarly independent. Perhaps I don't fully grasp the metrics yet. The chess glossary defines DTC as "any conversion of material" which may be "either a promotion or capture". D...

I'd like to comment on using WDL for computing the DTx tables. There can be two such uses: 1. When computing a DTx table, WDL data for the same table can save time, as it allows to mark draws so they can be skipped. Also when looking for won positions, those that are known to be lost can be skipped ...