Author: Eugene Nalimov
Date: 09:48:04 01/14/05
Go up one level in this thread
On January 14, 2005 at 04:37:24, Tony Werten wrote: >On January 13, 2005 at 12:41:13, Robert Hyatt wrote: > >>On January 13, 2005 at 12:15:52, Eugene Nalimov wrote: >> >>>On January 13, 2005 at 11:08:48, Robert Hyatt wrote: >>> >>>>On January 13, 2005 at 05:36:41, Tony Werten wrote: >>>> >>>>>Hi all, >>>>> >>>>> >>>>>when checking my own tables, I found out that the following (illegal ) position, >>>>>causes the Nalimov code( rather, the decompresssion code ) disabled further egtb >>>>>probes. >>>>> >>>>>No problem for normal use, just when you're doing something without checking if >>>>>the position is legal, it goes wrong. >>>>> >>>>>The position looks like it might have been optimized away, causing a probe >>>>>beyond the uncompressed size of the filechunck just read in, causing an >>>>>"invalid" flag on the tablebase, resulting in a disabling of the KNNkp >>>>>tablebase. >>>>> >>>>>[D]4K3/8/8/k7/8/1N6/p7/N7 w - - 0 0 >>>>> >>>>>Tony >>>> >>>> >>>>I believe this has always been a restriction. Since one way to compress the >>>>database (before the raw compression algorithm) is to weed out positions that >>>>are not possible, such as two kings on adjancent squares, both kings in check, >>>>pawns on illegal squares, etc. I suppose the probe code could be modified to do >>>>all the legality checks, but then it would have to be able to generate moves to >>>>see if a king is in check and the other side is on move, etc. It makes more >>>>sense for the chess engine to do that stuff since it knows about legality issues >>>>anyway... >>>> >>>>Perhaps Eugene will comment further... >>> >>>If you pass illegal position you'll get back either "unknown value" (if you are >>>lucky), or value for some other position. >>> >>>I definitely would not turn off further probing, but chess engine can. >>> >>>Thanks, >>>Eugene >> >>Aha... >> >>So this is something that was done by Tony's program, rather than the EGTB >>probe/decompression code? If I get "invalid" back, I just ignore it and keep >>going, I don't use that to say "this table is not present". In fact, I don't >>keep up with that, I just probe when I reach the right number of pieces and let >>your code return a value or a failure condition... > >Nope, it's the tablebase code that makes the path to the tablefile invalid >(making it NULL) >The code that gets executed is: > >L_TbtProbeTable => TbtProbeTable => comp_decode_and_check_crc=> error => > ptbd->m_rgpchFileName[side][iExtent] = NULL; > >wich will result in a failure on "FRegistered(iTb, side)" any next call for that >tablebase. I see, and I believe I now remember the reasons. TB probing code does not know what caused disk read to fail -- bad disk, or bad file, or index out of range (as in this case). To be safe and to not touch faulty file or disk (disk reads are slow, and chances are you will not get any useful information) it will not probe this TB in the future. Thanks, Eugene >Tony
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.