Author: Robert Hyatt
Date: 12:35:58 01/25/00
Go up one level in this thread
On January 25, 2000 at 14:02:01, Christophe Theron wrote: > > >If you consider that they were not using any pruning scheme and were (probably) >extending a lot, the numbers are incredibly good. > >If this sample is representative of DB's branching factor, then I have a >problem. I have worked *hard* to improve my move ordering at the time my program >was not selective at all, and I have never been close to this. > >Maybe I have not been very good at this, but as I understand nobody has ever >been able to get a BF as low as DB's with a full width search and a lot of >extensions as they did. > >Bob, don't you think it's strange? > > Yes and no. One thing I try to do is read what the DB guys say _carefully_. When we were getting reports about the 10 game (and 40 game) matches. Everyone was ballistic and trying to find anything to pick apart the statements by Hsu/ Campbell with respect to this. They overlooked something important: Hsu mentioned "we disabled the futility pruning in the q-search which slowed the chip by a factor of 10..." Most noticed the factor of 10. _I_ noticed the "we disabled the futility pruning". Because Hsu and I had had a _long_ discussion about this in r.g.c a few years back. I ran a bunch of tests using SEE, MVV/LVA and SEE+futility, and posted the results. Apparently he liked the data and implemented this quietly. We learned something about DB (or at least I did) in this simple discussion... Something much more important than the fact that DB trashed some 1996-era commercial micro programs horribly. I think there is a _lot_ to be learned about DB by studying the logs over time. I know _I_ am going to do so. Vincent has (for years) harped on DB's supposedly horrible branching factor and "only 10-11 plies...". We now know that (a) their branching factor was not horrible and (b) their 10-11 plies was really 14-15 plies when you count the hardware search. We learn more every day about the thing. While some only want to imagine that they used speed to cover up for sloppy searching (poor branching factor) or sloppy evaluation. Now we can _know_ a lot about what they did... For those that want to know of course. A few simply want to have no part of DB being as strong as it was. Nothing will convince them otherwise. And since it is probably "gone" nothing will ever convince them. But in my case I _know_. The thing was impossibly strong. It searched impossibly deep. And it did a very good evaluation to play strong positional chess. And it beat the best player in the world. At his own game (tactics). Not much more to be said. But a _lot_ to be learned in figuring out what they did and how they did it. I think the next few months will be interesting as more details come out from studying the logs. At least we know their branching factor now... > >>>>I don't think it would do "worse and worse". Any more than any other program >>>>would. Although it might do worse as depth decreases depending on what they >>>>did in their eval. >>> >>> >>>With such a "high" branching factor, you can expect to end up doing worse in >>>term of average ply depth than a low BF program. >>> >>>Of course, with their NPS, they start with a huge advantage. But if you draw the >>>curve of ply depth versus time for both DB and a modern commercial program, you >>>can expect DB's curve to be eventually reached by the commercial's curve. >> >> >>yes.. although their search will necessarily have fewer errors, since they don't >>rely on things like Null-move or forward pruning. Whether that is a good thing >>or not is debatable. But they don't have much of the fail-high / fail-low >>nonsense I see regularly. > > >Actually many programs prove everyday that using an imperfect pruning scheme is >much better than no pruning at all. Yours included (I don't mean your pruning is >imperfect). > >I see no reason to believe that this would change just because you are be able >to compute 4, 5 or even 10 plies deeper. > >Is it really still debatable? It was maybe, 20 years ago, but now we all know >the answer... > > > > >>>That's what I meant by "doing worse and worse". I could have written "doing less >>>and less good". >>> >>>Maybe I'm wrong because the singular extension stuff would compensate for this, >>>and the pruning system of commercial program would lose important information >>>than a pure alphabeta search. But I don't think so. >>> >> >> >>Impossible to say or predict. Hsu was a stickler for eliminating error, >>although he did mention that if he had done the PC version, he would have at >>least included the option as the code is trivial. > > >It is not that trivial because you have to think about all the consequences. I >think most chess programmers spend a huge percentage of their time in designing >and improving their selective algorithms. At least I do. > >I was not really meaning that micro programs could beat Deep Blue. My main point >is that not using a pruning scheme is somewhat... stup... Ahem... not really >optimal. > > > > >>>My opinion is that Deep Blue is much stronger than micros just because it has a >>>huge NPS. >>> >> >>I think that is a big part of it. However, it is still capable of maintaining >>that huge speed advantage while doing anything they want in the eval. They >>were apparently quite interested in King Safety, and spent a lot of time >>working on that. At zero cost... where mine is significant... >> >>I think the micro matches were simply 'interesting' things to try. I did this >>several years ago with Cray Blitz vs Chess Genius on the fastest PC available >>in the 1993-4 timeframe. CB blew it out horribly even giving Genius a huge >>time handicap. And we had a long discussion about the games. Everyone agreed >>that the real problem was that CB had a pretty good king safety evaluation, >>and Genius had very little. And it kept getting attacked and shredded in every >>Game. Chris Whittington even guessed the identity of the program as I never >>told who. He guessed it after looking at the horrific attacks it was falling >>into... >> >>Hsu reported the same things about 1996-era commercial programs which definitely >>were light on king safety... > > >That can be part of the explanation. But in many openings there is no way to >built an overwhelming king attack, and you have to play positions where the >micros do not show weaknesses. > >38-2 cannot be explained only by king safety. > > > > >>>But if you present things like this, it's not very sexy. >>> >>>So Hsu decided to use a totally different approach than the micro's. >>> >>>By not using a good known pruning system and introducing a new extension scheme >>>of your own, you present yourself as being a pionner. A genius that is so bright >>>that he has understood that what everybody else is considering as very good >>>(null move or similar recipes) is in fact rubbish. A guru that has invented a >>>bright human-like extension: the singular extension! >>> >>>In fact, Hsu is more a hardware and public relation genius than a technical >>>chess programmer genius. >> >>I wouldn't agree there at all. If you had ever met him and talked with him, >>that would not be a statement you would make... > > >At least he didn't show that he was a genius in chess programming. Was it? We >will never know. > >I can't deny that designing the chips is a great achievement, and that Hsu is >certainly a wonderful hardware designer. > >But I'm sorry, not using any pruning scheme, if it is really what they did, >sounds like a "political" decision. I cannot believe that Hsu is stupid enough >to really believe that DB plays better without pruning. > >It is either a huge professional mistake or a deliberate public relations >choice. You guess. > > > > >>>He had so much power available, that he could afford spoiling it just to look >>>brighter than every other chess programmers. >> >>He didn't "just had so much". He spent years building something to give him >>that much power... that was part of the 'total package'... > > >OK, he had all this power as a result of his very hard work. So he deserved it. >But the total package could have been much better with a pruning scheme. The >thing that has played against Kasparov was far from being finished. > > > > >>>In my opinion, Deep Blue as it has been programmed is much weaker than what it >>>could have been. That is not to say it is not very strong. >>> >> >>I don't think even Hsu would disagree. They cut it _very_ close for both >>matches, not even having a month to play with the real chips each year. I >>am convinced it could be 100-200 points better with a couple of years of >>hard work at tuning/testing the full-blown hardware... > > >Certainly. > > > > 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.