Author: Robert Hyatt
Date: 21:10:19 10/09/99
Go up one level in this thread
On October 09, 1999 at 23:26:16, James B. Shearer wrote: >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> It should play almost anything from 5 3 on down (blitz) or any standard time control up to 30 30. Is something broken that I don't know about? > >>>>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. :-) ) Sorry... I was looking at the game before the last one. Didn't really pay attention to the final result. I just noticed that about 1/2 way thru the second-to-last game, cpu went way down as did depth. It stayed at 3-4 through the last game... except for an occasional moment of blasting along when the students would take a breath. :) > > <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 All I can say about speed is that on the quad P6/200, it runs about 400K nps normally, with blips to 500K+ in endgames. However, it taking an unusual amount of time on one move doesn't guarantee that it 'failed low' at all when the machine gets loaded. Unfortunately I now can't tell exactly as the automatic script that cleans out old log files has run and deleted all those logs...
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.