Author: Robert Hyatt
Date: 05:56:51 04/27/01
Go up one level in this thread
On April 26, 2001 at 23:03:46, Vincent Diepeveen wrote: >On April 25, 2001 at 21:52:51, Robert Hyatt wrote: > >>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. > >40 games is what i get for diep within a day of testing with Jan. > >40 games of 3 hours a game or more. Then you have longer days there than I have here. I only get 24 hours per day here in the US. > >> >> >>> >>>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 > >Please post the implementation as done by Hsu. > >His 'general' definition leaves a lot of space to implement it. >The definition as you told me at icc once was having big gaps. All you have to do is read the JICCA. It was given there. And I left no big gaps. PV singular is obvious... FH singular is just as obvious. One day I'll send you a copy of Search() for Crafty that has this implemented so you can see how to do it correctly. > >>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... > >I do not want to discuss how i implemented the different extensions >i have in DIEP. I did a lot of effort for many of the extensions, >one i got for free from a very cool guy, whereas the >person claiming he invented the extension >he did so getting away publishing WITHOUT source code, not even pseudo >code. At least not in the advances of artificial intelligence where i >saw his article. If you are doing SE, then there is no reason to not discuss them. Their functionality and implementation are already public knowledge from the articles on SE by Hsu and company. If you are doing something different, then please don't call it SE, as that name is taken already and applies to a particular implementation. > >If someone has pseudo code of Hsu, i would welcome it! The JICCA article tells all... > >Just what it is: a move being margin S better as all other moves, >that leaves loads of space for implementations!! How? Seems perfectly clear to me... > >> >> >>> >>>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... > >No. Recaptures aren't definition singular moves always, depending upon >your definition of what a recapture is of course. > >One reply checks i have special extensions for, that's got nothing to >do with SE in my prog. > >The most rudest definition of a recapture in my prog is: "you capture >somewhere a piece and the next move you recapture on that field". > >Note those extensions take care that any of the hard tactical positions >there are left on this planet to solve, that those get solved at least >a few ply sooner! > >In general just extending every capture a bit >is giving tactical the biggest boost for a program together with >check evasion and a good qsearch! I don't agree. Ken Thompson did this in 1983. He then did a _lot_ of testing afterward and concluded that extending captures was a mistake. I trust his analysis. He extended every capture 1/2 ply in fact, which was explained by him in several talks... > >> >> >>> >>>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. > >Ah that's very cool. So the idea probably slowly developed then to >doing it in the qsearch then doing it in the normal search, then doing >it recursive... > > > >> >> >> >>> >>>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.