Author: Tony Werten
Date: 01:37:24 01/14/05
Go up one level in this thread
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. 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.