Author: Tony Werten
Date: 02:03:56 01/15/05
Go up one level in this thread
On January 14, 2005 at 12:48:04, Eugene Nalimov wrote: >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. For normal use, it should be a problem, most engines check for legality first anyway before probing. I assume your generator does that too ? Else it would be a problem. Tony > >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.