CCRL Discussion Board

Yes, exactly. I don't want to bother with successors, yet. The intuition might be wrong, btw, but the generator will figure that out soon enough. An end-game that is not generally won is not a good benchmark, as the win-front dies out very quickly. The main purpose of he benchmark is to get an idea ...

Indeed, from your remarks it is clear that you did understand less than nothing. But your apologies are accepted...

It is interesting you mention that it is likely to encounter more fallibility in the presence of more men. The philosophy on which DTR is based, (even if you make it work, by including the current value of the reversible-move counter in the index), s tht the fallibility in all phases is equal: if yo...

I think the metric I describe in the third post of this thread is the most useful choice for pawnles end-games.

Only DTR needs the tie breaker in the form of DTZR. This because in the limit n -> infinity the DnTM norm (= (SUM pase_i^n) ^ (1/n) ) the (sup-)norm of the DTM vector gets completely independent of the duration of any shoter phase. So DTR = DinfTM can no longer be used to order positions with equal ...

Indeed, and I am well aware of that. This is another reason why I switched from using Nalimov statistics to DTC: in DTC the tactical wtm positions with a hanging piece betray themselves by having DTC = 0 or 1. So to judge if an end-game is won I look if there is a sizable fraction of position that h...

I am writing the generator such that it can handle 6-men as well as 7-men EGTs. But although much of the code will be in common, some code will be specific to the 7-men case. So strictly speaking, it wouldn't prove anything if the 6-men generated this way are correct. I guess the best way to test ao...

I don't think a chess-playing program needs them. (I have never used Nalimov tablebases in a Chess program, though, and do not have a single one on any of my computers, so you should not automatically believe that what I think is true...) In fact the .tbs files are the only Nalimov files that are of...

tbs files contain an overview of the statistic of the EGT, (i.e. the number of positions for each DTM), not? They are simple text files, of a few dozen lines.

Yes, I had that problem too. Suddenly th link under my browser "favorites" stopped working, (it had been off and on for some time anyway), and only after a few days I discovered that the site was not down, but tht I was using an obsolete link...

Note that DTM and DTR are actually the two extreme cases of a DnTM metric, where n is a numbr that describes how to combine the time spent in each phase to a total time. This sequence of the number of moves spent in each phase could be seen as a vector, and the total winning distance as the norm of ...

I changed my opinion on the DTR metric (as others apparently did before me, without me properly understanding the problem they were pointing out): for tablebases that tore DTx as a function of position, rather than full game state (which includes also things like reversible-move counter), it is a us...

I followed your recommendation for the web-page titles. It s true that in 7-men EGTs you have so many pieces that it becomes difficult (and thus rare) to have them all different. But I am not only interested in the 4 orthodox piece types, and with more piece types the fraction that has doublets is m...

Now that I have started coding work on my 7-men EGT generator, I thought it a good idea to already put the description of its design and the algorithm it will be using on my website. So I have now devoted a section of 14 web pages to tablebases, in addition to the two pages I already had. You can fi...

Well, this is where you need tablebases in the first place. For positions that engines know how to win easily by itself, even at low depth, they offer no advantage. But there are many end-games with Rooks + Pawns or Queens + Pawns, where a simple evalution based on material and piece-square tables i...

... But I doubt it will on the average give better results than doing a normal alpha-beta search and relying on the hash table. Oh yes, it will. Try finding a checkmate in a 3-men end-game by alpha-beta + hashing, for a not-too-powerful piece. I have tried this many times, even with Joker, which ha...

... So your idea would only work for generally won pawn slices? The DTZ(k) metric, as hgm points out, does have the advantage over DTC/DTM that if there is a move zeroing the move-count, changing the phase, and winning, no other successors need be consulted. 'dz', the depth under the DTZ metric, is...

However, we shouldn't get hgm's EGTs confused with the definitive EGTs which this discussion board has so far focussed on. You might also be able to tell that I am distinctly unenthusiastic about proposed classification of endgames or P-slices into 'sensical/nonsensical', or of positions into 'bles...

My own interest in end-games is to improve play of my engine, and to determine end-game values of fairy pieces. For that purpose I am at just the opposite opinion as you: there is no future in pre-computing and storing tablebases, as their size and number grows just to fast with the number of men. A...

Perhaps I should elaborate on this, then. The judgement that a certain successor P-slice is non-sensical is is not a chessic one. It is something that follows from the calculation: To calculate, say Ka4b4c7d7Kh7, you need to probe successors after Pawn push or capture. If the successors do not exist...

For the format of the 6/7-men EGT generator I am building, I do plan to have each P-slice in a separate file. So their will not be anything like KRPKRP.btm, but I will have things like KRe2KRh7.btm, KRd6KRd7.btm, etc. So the matter of ordering of the different Pawn constellations will simply never c...

I am interested in compression methods, as I have not yet fully worked out the method I am using in my 7-men generator during building, and am not very knowledgeable on compression methods in general. (I know about Hufman coding, but that is about it.) I guess the requirements for compression during...

The diagonal symmetry is tricky, as by looking at only two pieces to decide if a position is in the tablebase or not, means that symmetry-equivalent positions differing only in the location of pieces you did not consider (i.e. everything except the Kings in Nalimov) now occur twice in the tablebase....

Leapfrog already works for 3+4, 4+3 and 5+2 with 2GB provided that white has a King. This is what I will be using: To have all white moves of one of the two groups that you alternate fall within memory, you need to store 5 different King locations, (using K-slice factorization) and 64 locations of t...

My first goal as a test-case and benchmark for what perfomance to expect will be to use the 7-men disk-storage scheme and in-RAM processing code to generate a 6-men tablebase for KQ*Q*KN!N!, not making use of the exchange symmetry of like pieces. Here N! means an invulnerable Knight, and Q* means a ...