Author: Robert Hyatt
Date: 10:30:09 09/07/00
Go up one level in this thread
On September 06, 2000 at 14:09:38, Uri Blass wrote: >On September 06, 2000 at 13:56:42, Robert Hyatt wrote: > >>On September 06, 2000 at 11:18:53, Uri Blass wrote: >> >>>On September 06, 2000 at 11:06:16, Robert Hyatt wrote: >>> >>>>On September 06, 2000 at 06:14:29, Amir Ban wrote: >>>> >>>>>On September 05, 2000 at 10:32:27, Robert Hyatt wrote: >>>>> >>>>>>On September 05, 2000 at 01:18:55, Mark Longridge wrote: >>>>>> >>>>>>>I was playing crafty the other day and white had a pawn on h7, and a knight on >>>>>>>g5, black's king is in the corner, and black has only it's king. >>>>>>> >>>>>>>There's absolutely no way black can win with just a king, but it STILL REFUSES >>>>>>>A DRAW request! >>>>>>> >>>>>>>It just seemed very odd ;-) >>>>>> >>>>>> >>>>>>It mainly depends on how you have things set up. And even if it is set up >>>>>>correctly, there are 'rules' that have to be satisfied before it will accept >>>>>>a draw. IE it has to believe it is a draw. It also has to get a draw score >>>>>>back from the search for 5 consecutive moves (3 for GM players) before it will >>>>>>accept or offer a draw. >>>>>> >>>>>>Just giving the position doesn't provide enough information... >>>>>> >>>>>>The log.nnn file is also needed. >>>>> >>>>>The position provides all the relevant information. >>>>> >>>>>It's your problem, not the opponent's to make sure your program behaves >>>>>reasonably. >>>>> >>>>>Asking the opponent to provide internal crafty parameters and logs is not >>>>>reasonable. >>>>> >>>>>Amir >>>> >>>> >>>>Your assumptions are wrong. The default setup _will_ offer draws. But it is >>>>possible that the user has disabled this and not remembered. The position >>>>doesn't say a thing, because of the rules I gave. Crafty has to find a draw >>>>score 5 moves in a row to offer a draw. The current search eval has to be >>>><= drawscore for it to accept a draw, and it won't accept a draw at all during >>>>the first 30-40 moves of the game. Based on that, I can't look at a position >>>>and say whether it should have accepted a draw offer there or not... It might >>>>have accepted after 4 more moves... who knows without seeing what went on in >>>>the _game_... >>> >>>This is a logical explanation for the fact that crafty did not agree to a draw >>>but better rules should tell it always to accept a draw if it has only a king. >>> >>>Uri >> >> >>It should, unless it has been disabled by the user. I can't see any way to >>reach a king only position without crafty seeing it in the search a few moves >>ahead of time. > >I agree that cases when crafty did not see a draw or a loss for itself in the >last few moves are not common but I am not sure if they are impossible. > >The only cases that I can think about(assuming that there are no unknown bugs) >are: > >1)A case when crafty cannot see something because of null move pruning. > >2)A case when crafty believed 5 moves ago that another line was leading to a win >and only later understood that it is not good and had to sacrifice to get a draw >position when it has only a king. > >Uri Turns out I get to take full credit for breaking this myself. accepting draw offers is _off_ by default. I changed something else and decided to make the switch name match the function (It originally read 'backward'.. if it was non- zero it did the opposite of what the name implied... I fixed it but forgot to then make it default to 1. As a result, draw accepting has been off for a good while, except for special cases. The game in question will result in an accepted draw offer, after one search is made. now.. my error. (aren't they all?) :)
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.