Author: Robert Hyatt
Date: 12:42:53 06/27/98
Go up one level in this thread
On June 27, 1998 at 10:15:40, Vincent Diepeveen wrote: >Hello Bob you're lately telling us a lot of new facts, > >I remember that some time ago (2 years perhaps?) >we already knew the DB speed. i claimed that getting 18-20 ply >would be no problem for them if they stripped some extensions, >improved move ordering and used nullmove. > >At that time you told your audience that getting 20 ply was >*impossible* and challenged me. > I don't recall *ever* saying 20 plies was "impossible". I might have said *impossible* using their search, because I know that they don't use null-move at all, based on comments from Hsu. Which means a branching factor of 5.5 roughly. If they used R=2 null move with the attending effective branching factor of 2.5 or so, 20 plies is doable. If I could search 1,000 times faster *right now*. I would search to a depth of 12 + log (base 2.5) 1000. the log is approximately 7, which means where I do 10 now, I would do 17 at 200M nodes per sec. Where I would do 12 now, I would do 19. The math is simple. THeir NPS is not new... >Right now my program GETS 20 ply in several middlegame >positions after 24 hours of analyses (and i'm not referring to >positions where you need to make a forced move like recapture), >but i'm also in the pruning buiseness, so probably this doesn't count >in your eyes as some stupid variations get pruned by Diep. > what your program does doesn't matter. they aren't selective. you are. the searches aren't comparable in any sense of the word. >Note that very important is the fact that i'm having 80MB of ram now, >under NT i use 60MB of hash under DOS 64MB. It appeared that >big hashtables at analysis level give a lot (which is rather unsurprising). > >Now how big was my surprise when reading next: > >>Again... if DB used null-move R=2, with a search like mine, they would do 20+ >>plies in middlegame. They do extensions instead. I do 12 plies at 200K nodes > >How can they at hardware which is slower than was expected few years >ago (i still remember an email from one of the teammembers very well >where they expected to make a chip which got 5-10M nodes a second, >and that has become finally 2.5M) >get suddenly 20+ ply without my 'dubious' forward pruning, but with >the stuff discusses in RGCC, and they even could search deeper >in your opinion? their 2.5M NPS was most likely the result of spending a year to (a) make the eval hardware more complicated (b) adding checks to the q-search, which early versions didn't do and (c) detecting repetitions in the hardware, which older ones didn't do and (d) adding other things like endgame database probes into the hardware. I based 20 plies on *my* program. I generally do 12 in middlegame positions at 250K - 300K nodes per second. Going 1,000 times faster, with my current branching factor of around 2.5, that leads to a 19 ply search (or better) in equal positions, based on nothing but understanding that new depth = old depth + log(base 2.5) 1,000. > >This needs some explanation! already done.. > >>per second. They are 1,000 times faster... with a branching factor of roughly >>2.5, what is log base 2.5 of 1000? That's my search depth at that speed. So >>*obviously* they are doing something else. You compare your 12 plies to their >>12 plies. I say that's total hogwash. > >Ok ask IBM for old printouts of the match and we can easily compare their >mainlines to our mainlines. > >Don't do whether their 12 ply is in fact 24 ply or 13 ply. > >12 ply is 12 ply, if you use nullmove you run zugzwang risks. If you don't >do checks in q-search you even miss obvious mate threats last couple >of ply, if you prune a lot you might sometimes miss something like >heavy sacraficing for a mating attack; but lucky none of this all happened >in the games. > >Their 12 ply aren't more holy than mine 12 ply. I admit: i prune, so certain >stupid lines which might win might get pruned. There were no >difficult ! moves played by Deep Blue, no difficult sacrafices, no >mate in 40 announced, and win in 23 ply (23 ply for Diep: Kf1? in game >II, where Kh1! wins forced) was missed by Deep Blue. they don't do null move. they do do checks in qsearch. your point would be, after knowing that, ?? yet you continually get beaten by "crafty" which, according to you, has (a) a poor search; (b) poor evaluation; (c) no "mate" extensions; (d) no sophisticated selectiveness; (e) a simple and ineffective quiescence search. I'm afraid that in this case, 2+2 = 4. I'm doing *something* right, otherwise you are doing something *terribly* wrong. Either explanation is possible. But you ought to stop putting your program up as "the epitome of computer chess programs" when comparing what you can do to what Deep Blue (or another program) does. I tend to notice results, rather than chest-pounding and hand-waving. > >Yet it plays a horrible move which is only 1 ply deep (12.Bxg6? in game 4 >after the moves: > 1. e4 c6 2. d4 d6 3. Nf3 Nf6 4. Nc3 Bg4 > 5. h3 Bh5 6. Bd3 e6 7. Qe2 d5 8. Bg5 Be7 > 9. e5 Nfd7 10. Bxe7 Qxe7 11. g4 Bg6 12. Bxg6 hxg6) should I point out how many horrible moves *your* program plays in a game? Would that prove anything at all? When you post your games where you beat Kasparov here in CCC, I'll check 'em over for horrible moves. Exactly when can I expect to see those games? > >This move Bxg6 can be easily prevented if a program knows that >after hxg6 the simple pattern g6,g7,f7 open h-file is not a bad doubled pawn. > >This is a beginners fault of 1 ply. So how deep did Deep Blue search? > >Please test your programs at it. If i remember well this pattern is also in >psion. > >Vincent g6 g7 f7 *can* be a problem. It depends on white's h-pawn and whether he can get rid of it and use the open h-file. So you can't just say f7/g6/g7 is ok... because if white dumps his h-pawn, or rook lifts to e3-h3, black is in a *world* of difficulty.
This page took 0.01 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.