Author: Uri Blass
Date: 01:57:13 02/08/04
Go up one level in this thread
On February 07, 2004 at 18:43:59, David Dory wrote: >On February 07, 2004 at 18:26:00, Uri Blass wrote: > >>I started to work on having some evaluation about endgame and >>I wrote something to detect draws in KP vs K. >> >>It does not detect every possible draw but at least hopefully when it detect >>draw it is correct if I have no bugs. >> >>Tablebases is not a solution because they are too slow and I believe that >>generally functions are better because even in case of having tablebases if I do >>not probe them in the qsearch I may get KP vs K that I need to evaluate without >>tablebases and I want to return correct score without looking in tablebases. >> >>I read that yace is using bitbases even for 4 piece endgames when the bitbases >>give only win draw loss information and I guess that the bitbases were >>calculated from nalimov tablebases. >> >>I wonder what other people do in KP vs K endgame in case of not looking in >>tablebases(because the program does not support tablebases or because it is a >>qsearch node). >> >>Do they have a special function to detect the result or do they assume that >>cases when they get KPK in the qsearch are rare enough when they use the 5 piece >>tablebases because in most cases they probe the tablebases earlier. >> >>Uri > >As you say, I believe most programs would access their tablebases earlier. > >I always applaud adding knowledge to the endgame into the program itself, >though. Can you give an example (diagram) of a position your code fails to find >the draw with KP vs. K ? The problem is not to find the draw when you already in drawn position of KP vs K but to evaluate the leaf Kp vs K as a draw because with wrong evaluation you may plan to go to drawn endgame and miss another move that gives better chances. Uri
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.