Author: Robert Hyatt
Date: 18:52:51 04/25/01
Go up one level in this thread
On April 25, 2001 at 20:02:27, Vincent Diepeveen wrote: > >I'm nodding bigtime here. SE is good to solve testsets, but not near >what recaptures and check extensions give. >As far as we know Deep Blue only played 10 practice games of around 30 0 >level against Rebel 8. Actually we know a lot more than that. We know they played 40 games as someone _else_ reported here after attending a lecture by one of the team last year. The 40 game match ended something like 38-2 but the original poster can give the exact quote. We also know it played hundreds of games vs GM Joel Benjamin (DB Jr). And we know it played dozens of exhibition matches against GMs at various conferences. I watched it play Byrne 6 games at a supercomputing conference exhibit hall. > >So that's very little testing. So their only data for SE are tactical >positions i assume. > >This means simply that i have way more data about SE as they have. Again, I don't believe you have any _real_ SE data. SE as described and implemented by Hsu. Which includes both PV_singular and FH-singular tests... I have code that does this, and it is very expensive at present, although a few are working on tuning it better. Tell me _exactly_ what you have implemented and are calling SE... > >Jan Louwman is auto232 playing a lot of games for me nowadays, >for which i thank him bigtime! > >Several versions jan had there played WITH recapture extension and >with Singular extension. That makes little sense. SE should subsume both recapture and one-reply checks... > >I did not notice *any* difference whatsoever at levels of around 3 hours >a game or more (k7-900 to 6 hours a game celeron500-celeron500) > >However at level of 30 0 the difference was very obvious in the advantage >of the versions which did all kind of extensions! > >I don't need to mention that the SE version hardly gets over 10 plies >of search depth. Note SE only costs a ply or so at 3 hours a game. >The real expensive things were extending captures, recaptures especially. > >Those cost me the biggest part of the search depth. > >Yet searching dual i see the difference very quick between the different >versions the SE + recapture + matethreat version simply is dying when >getting around 10 plies of depth. > >I use it btw with a reduction factor of 3 ply so i can only apply it >at 4 plies from the leaves. Whereas DB most likely uses it only 6 plies >away from the leaves. > >I also tried it at 5 and 6 plies away from the leaves, but most tactical >increase in solving testset positions are the check extensions and >recaptures. > >Check doesn't cost me much actually but those extensions are over the years >heavily worked at. > >However SE DECREASES the b.f. considerable. >Even worse are recaptures. > >So it's questionable how long i keep those extensions inside my >program! > >I already threw out recaptures. It just costs me too much! > >Now i need to note here that in qsearch i do not prune on alpha, >so a lot of tactical things which others NEED to see using recaptures >i detect in qsearch as i try all interesting moves there. > > >I do not know who invented nullmove. Some one already talked in 1979 >about it, but not called nullmove then. David Wilkins did in his paper >about Paradise. > >Who invented nullmove unofficially? I first heard about the "idea" in 1977 from Donskoy (Kaissa). Don Beal wrote the first technical paper about the idea. He is generally given credit for the idea. > >I heart rumours that some commercial did around 1986 or sooner? > >Around 1989 Frans Morsch started to use it in normal search >everywhere and always (recursive)? > >3 things speed me up bigtime > a) alphabeta pruning > b) hashtables > c) last plies pruning with qsearch (nullmove actually with qsearch) > d) recursive nullmove in normal search > >A and C you of course can invent yourself easily, though the >usage of a qsearch i find very elegant. Most commercials you probably >included with Tiger know a lot about pruning last plies. > >B is of course also not so logical but doable and with a load of >RAM one invents it easily. Also Zobrist hashing >is very natural to figure out, though if i had to figure it out >myself i would probably go for a similar algorithm which would >eat a few cycles more. > >The real hard thing to figure out is the recursive nullmove in search. > >The inventor of that really needs a big award! > >> >> >> >> Christophe
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.