kronsteen wrote:syzygy wrote:But I'm not sure how that helps much, as you'll need the subtables in DTZ50 if you want to use kpppkpp in DTZ50.
Wrong. DTZ(50) needs only WDL(50) for daughter endings, not DTZ(50).
syzygy wrote:I think the idea is that to generate kpppkpp in DTZ50, you only need all subtables in WDL50.
This is the main strength of the “dual metric” approach : as soon as you have 7-men full set in WDL(50) format, you can compute DTZ(50) table of any 7-men ending you want (even kpppkpp first if it is your wish), regardless of other DTZ(50) tables that already exist.
Even if a future generator is designed to build DTZ(50) and WDL(50) tables at the same time (WDL(50) being a “sub product” of DTZ(50)), keeping only WDL(50) first due to space storage limitations (and waiting for hardware upgrade for DTZ) might be a sensible approach, as DTZ(50) tables are something like 5 times bigger, and their size can be hundreds of GBs.
The fact is DTZ(50) info will not necessarily be sustained everywhere from initial position to mate, but only in “interesting” phases. Taking kpppkpp as an example, if you succeed in converting to kqppkpp, maybe this ending will be kept in WDL(50) format as WDL info added to your playing ability will be enough to win this in general. But should this ending convert to kqppkqp, you may want DTZ(50) info back as this is a difficult ending. This is perfectly possible.
syzygy wrote:As a temporary solution to have something useful while waiting for 100TB hard drives, WDL seems a lot more interesting. (Another option would be 5-state WDL50+, if the difference in size turns out to be small enough.)
syzygy wrote:Btw, for tables with pawns you can look at maxDTZ for each pawn slice. Most likely the majority of slices will have small maxDTZ. It should be possible to leave out those slices from a DTZ50-table and let the engine revert to the corresponding WDL50-slice.
kronsteen wrote:Hmmm. It is not just because DTZ is small that winning line is easy to find. In kqpkq for example, preliminary required wq moves before touching the pawn in order to preserve a difficult theoretical win thereafter are sometimes rather mysterious, and even at DTZ depth of 3 or 4 one can easily go astray with only WDL support (ok this example is not perfect as I think that no kqpkq pawn slice has small maxDTZ, but it may well be the case in kbppkbp for example, with the problem above remaining).
Also, cutting a TB into pawn slices might be impractical if the indexing scheme is not built upon this notion, and it is probably unwise to require anything other than "best possible expected performance" for indexing scheme.
guyhaw wrote:But a reason why one might go WDL(50) some way before kpppkpp, at which point one goes DTZ(50) is that ... with a 'sliced-EGT' index ('placing' both sides' Pawns first), the endgames with fewer Pawns have bigger slices. This means that the indivisible KQRNKQR woudl be very inconvenient to do as DTZ(50) but WDL(50) would be more tractable.
[ I think MB might have already done the KPPPKPP~ EGT, the '~' indicating that conversions are only to Queens. ]
Given that one has a WDL EGT, only a delta-WDL/WDL50 EGT is required, noting the differences between WDL and WDL50. In fact, I think someone suggested using the 4th bit for 'decisive but beyond 50 moves' (but then it's not clear whether it is a win or a loss).
Not sure with modern disc technology whether Hyatt's establish 8KB blocksize for Nalimov EGTs is still optimal. Would seem a pity to shrink 8KB of delta-WDL/WDL50 EGT down to next to nothing because of its sparness, and then to be bringing in only those small bits on each disc transfer.
syzygy wrote:The indexing scheme used for generation will be built upon this notion. Otherwise the generator will not have the ability to generate the table slice by slice, which will lose a lot of performance. Also DTZ almost demands a slice by slice approach.
syzygy wrote:The indexing scheme for the compressed format may be (and possibly should) be a different one. However, it seems to make a lot of sense for many reasons to also base that scheme on pawn slices. In a way the different slices have as much to do with each other as with any of the subtables.
syzygy wrote:True, this might allow an earlier generation of DTZ50 for kpppkpp. Still, I don't see why one would be happy with a DTZ50-table for kpppkpp without also having the (non-trivial) subtables in DTZ50.
syzygy wrote:[ I think MB might have already done the KPPPKPP~ EGT, the '~' indicating that conversions are only to Queens. ]
However tempting, that sounds like something to be avoided if the aim is to generate the full set. Freely quoting a post by Kirill early in this thread, focussing first on the highlights will probably have the effect that the remainder is never generated.
syzygy wrote:I don't know if it is better to compress WDL (or WLD50) and its delta with WDL50 (or WDL) separately, or if it is better to compress the information as one 5-state table. I suspect the latter, but without experimentation that's only speculation.
kronsteen wrote:Indexing scheme must be kept free, but if cutting TBs in pawn slices is really the only sensible solution for best performance, then so be it.
Easy : this is because some endings are far more likely than others to occur in practical games. Ask the question to strong chess players “on what 7-men endings would you like to get perfect knowledge in order to improve your game” I would bet that krppkrp would come first, followed by endings such like kbppkbp, knppkrp, kpppkpp, kpppkbp, etc… and, on the other hand, every pawnless ending would be essentially seen as worthless as they almost never occur.
If at some point we get full WDL 7-men set and are up to start DTZ, having those statistics in order to target most likely endings first would be a possible and sensible approach, as it would be best suited to go for quick results for practical players (which form the biggest contingent of people interested in TBs, I believe).
guyhaw wrote:I attach here, zipped (as .pdf is unacceptable!)
guyhaw wrote:Incidentally, does anyone know about the old, and now sorted, 'KNNK bug' and the 'transparent pawn' bug in FEG?
Users browsing this forum: No registered users and 1 guest