CCRL Discussion Board

... The only exceptions I can think of are Rooks and Bishops: e.g. for a Rook you could make a slice that also contains all moves along ranks or files. So you would not fix the Rook, but only one of the coordinates of the Rook. (In other words, a Rook is a two-dimensional piece, which can be factor...

I understand how you do the first pass, but how are you going to do the passes for the other white pieces? How are you going to do the moves with these, if you only have tables where they are fixed to certain squares? As we can generate the won wtm positions in any order, we might as well generate ...

I am not sure I completely grasp the idea of the subset EGTBs. Currently I generate these simply together with the main one (as they are so much smaller this hardly involves any extra work), hiding them in the broken positions. But this might not be the smartest thing to do when generating on disk....

No, you did not fully get it. You would go through all the overflow bytes after cycle 12 (before writing away every chunk of data for that cycle), but you would not touch the overflow bytes on cycles 13-22. Cycle 13 would start with all the quickDTx 0, 1 or 15, where 1 means DTx=12, and 15 means DT...

... The last two moves of the treee thus move black pieces, and by having all black constellations for a fixed constellation of the white pieces in memory (storing them as a contiguous 'chunk'), these two moves would remain in the memory-loaded data set. By splitting the tree at the root in sub-tre...

Another thought on storing the EGTB in RAM while building: We could split the DTX field into a 4-bit frequently accessed part ('quickDTx'), plus an 'overflow' byte stored elsewhere. The 4-bit field would encode 'undecided' positions as 0, positions that have DTx specified in the overflow byte as 15...

A generator that is streaming IO-bound (as opposed to random access bound) would be a major advance. Well, I think this is what my algorithm should be able to deliver: For a 3+3 men EGTb, say, I would split each cycle in two passes, one pass treating the (retrograde) moves of first white piece plus...

Ok now I see where you are coming from. Sounds quite nice and I like the idea. Compared to the disk access times the actual compression and decompression wont take very long. I will think a little more about it too, as I am with my own egtb-generator currently facing the same problem - how to overco...

Well I am no expert on compression either, but I think that encoding during generation might only work for generally drawn endgames. For others it might be difficult, for example if you have a block of 256kb and you find you need 1 more bit at the beginning of the block, you will have to shift all b...

OK, thanks. It seems that a fully unsymmetric one (w.r.t. piece exchange) like KRBNKQ takes about 3GB after compression. That is only about a factor 3 compared to the 8GB an uncompressed 6-men would need. So your 20MB/sec is a bit optimistic at any rate. But, more importantly, there is no reason wh...

The only real problem I encountered yesterday when trying to generate my first 6-men tablebase. It would take the program 1474 mb ram to generate it (462*62*61*60*59* 2/8) My computer wasn't anymore able to hold it in ram, so I wanted to ask here, whether you know of any efficient algorithms to com...

Hi Edmund! Great to hear about your progress! Looking forward to use your generator! About the license, I think any OSI -approved license should be fine. Personally I like zlib/libpng license , because it is short enough so someone might actually read it. :) Thank you Kirill, I have taken your prop...

Hallo! In the past months I have been writing a bitbase generator. Currently it only supports pawn-less endgames and I haven't implemented the optimization of n-like men, which I want to do in the upcoming days. I tried generating some 5men endgames and it produces the right number of indexed positi...

jkominek wrote:Since you are thinking very general, can you make the position generator work for arbitrary WxH rectangular chess boards, with and without castling and en passant?

john

I am a fan of bitboards so the whole code is based on them. But the algorithm in principle would as well meet your requirements.

I am working on a very general bitbase generator that works with n-men. But still there are some problems for >6 men egtbs. Till now all Tablebases could be generated mainly from ram for larger tablebases new solutions will have to be found.

h.g.muller wrote:Is that a typo?

sorry, DTZ and DTR

Aaron Tay's focus on EGTs is good news, but arguably ripe for a review and makeover. Two examples: 1) DTZ EGTs are not 'just theory' but have been generated for 3- to 5-man EGTs, and (obviously) for 6-man P-less endgames where DTZ == DTC. 2) [ DTR EGTs are however still just a theoretical concept. ...

Currently the DTM-metric is the most common format (eg Nalimov tablebases) and it doesn't support the 50 moves rule. It shows a win, if you convert to a won subendgame that takes more than 50-moves to complete. I don't know of any DTM metric-variation that considers the 50 moves rule. This feature i...

DTM tries to minimize the number of moves to mate DTZ tries to minimize the number of moves to the next zeroing move (in pawnless endgames: captures) It can be that there will be a capture in 35 moves in DTM, which in continuation leads to the quickest mate. But it is in this case possible for the l...

These guys don't lack the financial resources anyway. Good Idea!

Brilliant, works fine!

Thank you for your help!

Hallo! Sorry for this off-topic post, but I would need some help please. After changing my emailadress on my board-account on Talkchess.com my Account was disactivated. This happened some weeks ago and since then it didn't get unlocked. And as there are no emailadresses of any of the moderators publ...

It looks like krppkrp is quite far away. I have a correspondence game going on with this material! KRPPKRP is actually very close. Calculating the P-slices you need for that correspondence game is almost trivial with current computer technology. I don't know exactly where these Pawns are on the boa...

Done !