Author: James B. Shearer
Date: 20:26:16 10/09/99
Go up one level in this thread
On October 09, 1999 at 15:37:23, Robert Hyatt wrote:
>On October 09, 1999 at 13:16:39, James B. Shearer wrote:
<deletions>
>> Drawing 0 increment games against a computer is not so easy. In this
>>regard it is polite of crafty to offer a draw in KR vrs KR instead of playing on
>>for 50 moves.
>
>It should offer a draw, except in two cases: (1) playing a computer, as the
>(C) operators are occasionally obnoxious and offer draws when losing. I just
>have it never accept/offer with (C)s unless I know them personally; (2) if you
>get below 30 seconds left with no inc (I notice you like 5 0 which is really
>brave, btw. :)
I'm not playing 5 0 because I like it, this is the only time control
your formula allows me to play (I also played a few 2 1 games a while ago but
this really is kind of hopeless especially with the interface I'm using and my
rating got knocked out of range). I expect I would do a bit better at 3 3 or
1 6.
<deletions>
>>>BTW the last game (the one you won) was exactly the right kind of strategy for
>>>a bogged down machine... the ending position was a 'null-move killer' type
>>>position as it was generally doing 3-4 plies for 90% of that game, where it was
>>>normally doing 9-12 plies in most of the others...
>>
>> The last game was a typical win vrs a computer. The computer already
>>one pawn up, grabs another on the queenside and gets mated on the kingside.
>> However I don't understand the 3-4 plies bit. Even if you were slowed
>>down by a factor of 4 this would be 1-2 plies so you should still have been
>>getting 7-10. The losing move was 25 Qxb7. Checking with crafty v16.19 Qxb7 is
>>selected through ply 8, fails low and is eventually rejected in ply 9.
>
>
>for that game, crafty was getting roughly 1% of one cpu. between moves 15
>and 40 it was doing almost always 3 plies, with an occasional step up to 4.
>And on a couple of moves, almost normal depths. Nice 20 (Linux) says give
>me 5% of one cpu if there is another compute-bound process, and give him 95%.
>That just crushes the search, and it would probably be worthwhile to turn off
>threads when it sees this happen.
Are we talking about the same game? Scrappy resigned after its 31th move
(it's mate in 1) in the last game. (Maybe you are confusing this game with one
of my numerous (4) other wins. :-) )
<deletions>
>>Scrappy's move 27 qc7 was also inferior allowing mate in 5. Again checking with
>>crafty v16.19, qc7 is first selected in ply 5 then fails low (quickly resolving
>>to -Mat05) in ply 8 and is eventually rejected. Scrappy apparently saw it was
>>in trouble as it took 29 seconds on this move (3 times as much as any other) but
>>was unable to find a better move in time. This is consistent with a depth of
>>7-10 plies.
>
>
>if 30 seconds isn't consistent on that machine, as it is pretty quick to get
>thru 8, never taking 5 seconds that I can recall. However, in this position,
>the current version starts sensing trouble (score drops) and it starts to use
>more time, which only lets the score drop lower since it is already in trouble.
>
>
>
>> I think you have an absolute upper bound on search time but in a case
>>like move 27 where scrappy sees the move it's going to play gets it mated and
>>still has some time (almost 3 minutes here) it might be better to keep searching
>>a while.
>
>Probably right. the upper bound is 5x the normal target. Which is almost
>always enough to finish the current ply (where the fail-low has occurred).
>If it couldn't be 'repaired' another ply isn't going to help, as it still
>thinks the losing move is best...
Well on my machine (233 MHz K6, crafty 16.19) Qc7 fails low in ply 8
at 19.04 seconds. This is resolved to -Mat05 at 26.25 seconds. Qa6 gets a ++
at 2:38 (158 seconds) which resolves to -4.36 at 2:46 (166 seconds). Ply 8
finishes at 3:05 (186 seconds). So if scrappy was getting 5 times the speed of
a 233 Mhz K6 and had a target time of 6 seconds, scrappy would see the mate but
not be able to finish the ply (or even find a better move) in 30 seconds. This
may be a bad case as the normal move order may not be very good when the issue
is avoiding mate at any cost.
James B. Shearer
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.