Author: Paul
Date: 11:40:20 11/13/01
Go up one level in this thread
On November 13, 2001 at 10:03:39, Dieter Buerssner wrote: >Thanks a lot Paul. > >Did Ernst A. Heinz comment on some unusual cases? For example this nice position >from Tarrasch, "Das Schachspiel": > >[D] 4N3/8/6p1/8/8/7p/5K1k/8 b - - > >1...Kh1 2. Nf6 Kh2 3. Ng4+ Kh1 4. Kf1 g5 5. Kf2 h2 6. Ne3 g4 7. Nf1 g3+ 8. Nxg3# >(White to move, also wins) > >The mate position is KNKP, where in your list this is not considered. No, doubt, >this will not play a role in practical games. However it leaves a (very small) >ungood feeling, when you know, that you make your program purposley blind for >some special study like positions. I think, this would be no problem for an eval >function, to give N vs. P(s) allways a positive score for the P (which I am >actually doing). This will heal itself by the search. However, when you cut in >the search too early, it will be blind for this forever. In the text of the book just before the table, Heinz divides the EGTB's into classes that can be roughly treated in the same way. The table then shows one of those per entry. So KNKP is handled in the text, as Tim Foden already mentioned (nice to see there are more guys with scanners around ;). Ernst Heinz doesn't just use 'knowledgeable encoding', but also 'knowledgeable probing' and 'knowledgeable scoring' ... together: 'knowledgeable querying'. So he takes care of all the exceptions in code and explicitly mentions your KNKP case in section 6.4, handling it with code in the interior recognizers. He also gives examples of the coding required to handle exceptional cases. IMHO it's all very clear and precise. In addition to what Tim already wrote: "KBKP, KNKP. The endgame KBKP features rare mate-in-1 positions with the KB side to move where the KP King is trapped in a corner by its own Pawn and the KB King. The endgame KNKP features rare mate-in-<=7 positions where the KP King is trapped on the edge near a corner by its own Pawn and the KN King. Our KBKP/KNKP recognizers back off and fail if they spot situations with a potentially trapped KP King. All other non-drawn KBKP/KNKP positions are won for the KP side and we score them as shown in Table 6.3." >BTW. If you ever should be the black side of this position on an internet chess >server. Just don't move. After some time, you will see the message: "game drawn, >Black runs out of time, and White has not enough mating material", or similar >:-) :) ... nice ... but I don't think you'll ever see me on a server ... too nervous a person for that. :( >Did Heinz also mention, how he handles the stalemate problem for the "allways >won" cases? See above. >And at last, I have found a very small improvement. For w/d/l cases, it seems to >be assumed, that 4 positions are encoded in one byte, while it is possible, to >store 5 positions in the same space. Ha! ... he knows everything: "... (draw, loss, win) which easily fits into 2 bits". I also remember reading somewhere that he doesn't want to make the en-/decoding extra complicated/slower by using less bits, but can't find that comment right now. Lastly, I think there are also other minor cases that can be improved, e.g. like KQK, using 4 bits for 10 possibilities ... but that's *very* minor, indeed. >Regards, >Dieter Groetjes, Paul
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.