guyhaw wrote:An exchange between a 'Guy' and a 'Guido' must be a rare thing ...
When Pawns feature, and only the a-h symmetry applies, stats from various programs should agree - after (as with FEG.lof stats) dividing by 2, 4, 6 or 12 as necessitated by 'like pieces'. It is difficult to impossible to compare Nalimov and FEG stats for P-less endgames.
Without Pawns, the exact stats depend on the treatment of 'both Kings on a1-h8' positions. Wirth removed all functional-duplicates; Nalimov lives with (a likely) two positions which are functionally equivalent.
The convention has been to include 'en passant' situations, which was perhaps why none of Ken Thompson's EGTs featured Ps on both sides, but not to include consideration of castling. There are some studies where castling is done in the main line of the solution.
With all EGTs, it is possible for a highly visible position, e.g. a maximal, to be unreachable from the initial array. Because I don't have the means to filter out all such positions, the maxDTx figures quoted are prior to any such filtering.
Agreed: it would be a strange error indeed that produced .tbs=.lof stats-agreement against the backcloth of an incorrect EGT.
Eugene has said that his one and only programming goal for the EGT-generator has been performance. He can push the limits on the compiler because he writes compilers. I am inexpert in his code and can't comment further.
You are incorrect to say that "if White has no win in m moves, Black cannot lose in m moves": Black might have a forced conversion to loss in another endgame. An example of this extremely rare genre is invited. EGT-generation to the DTM metric requires a minimum-DTM to be calculated first so that all follow-on-endgame positions are backed up: this is not so for the DTC and DTZ metrics. DTC/Z EGTs, besides being smaller than DTM EGTs when compressed, can dispense with subgame-position-inheritance in the first one or two cycles.
EN's index-scheme avoids positions with unavoidable-stm-checks in, and therefore gives smaller index sizes.
For reference, EN's KQPKRN index has 16,048,887,360 wtm and 17,032,882,752 btm positions. At 1bit/position, that's 2GB right there.
g
Hi my dear homonymous,
Also with pawns different programs couldn't always agree, because for example in my program there is an option which excludes some illegal positions because unreachable. The test is clearly rough and not exact, but equally interesting for analyzing such cases and is made doing one back move, so for instance in the simple kpk ending all the positions where the white pawn in the second row gives check to the black king are illegal even if the black has to move. In this specific case I found:
Legal positions without this check: 81664 (white moves) and 84012 (black moves)
Legal positions with this check: 81660 (white moves) and 83622 (black moves)
This option cannot be used with retrograde algorithm because would cause a crash, as it is easily foreseeable.
I don't use normally this option because it costs too much in time and more of the gain obtained avoiding the calculation of these positions.
For endings without pawns my program remove duplicates as Wirth does, while I don't consider ep and castling in the calculation of TBs. ep is considered only when the TBs are interrogated, but it is not always exactly the same, as was demonstrated to me some years ago by Bob Hyatt and others in CCC forum.
I too have difficulty to interpret EN code, but at first sight I imagine it is very efficient.
About my statement: "if White has no win in m moves, Black cannot lose in m moves" you are right but I'm right too!
I was speaking of the fact that I don't have to execute the cycle m of the black and this remains true, because during a cycle I examine only positions of the main TB, not of the derived TBs. The forced conversion of the black has been
computed before. But this is an easy case because the conversion is forced and this position is immediately solvable, while the main difficulty is when I have to compare results obtained by non-forced capture or promotion moves with results obtained from "normal" moves to choose the best result. Excuse me if I have not been clear in my last message.
For checking my program I run all 3 and 4-men TBs with the three different method, obtaining the same identical results (binary files and statistics) with all files in RAM. As a consequence my algorithms should be right in general even if I continue finding errors. There is still only an unknown error in some TBs calculated with the retrograde
algorithm if I use a 3 MB RAM, insufficient to keep the files in memory.
Your last sentence about DTM, DTC and DTZ is not completely clear to me, because I always considered only DTM, and the implications of DTC and DTZ are not known for me. The files of Nalimov are about 10-15% lesser than mine. For both the kqpkrn files the dimension of my (not yet generated) TB are 18,719,406,720 bytes, which is
inside the mentioned limits. But EN seems to paid this reduction with the non-reversibility of the indexing, while from my tables it is possible to extract any position with an assigned results or combined results.
Ciao
Guido
P.S. I can't be useful to you for the question in your new last message at least ... for now
