Author: Robert Hyatt
Date: 21:32:02 07/23/02
Go up one level in this thread
On July 23, 2002 at 18:32:13, Uri Blass wrote: >On July 23, 2002 at 15:46:34, Robert Hyatt wrote: > >>On July 23, 2002 at 11:48:02, Uri Blass wrote: >> >>>On July 23, 2002 at 11:36:36, Robert Hyatt wrote: >>> >>>>On July 23, 2002 at 10:40:00, Uri Blass wrote: >>>> >>>>>On July 23, 2002 at 10:06:18, Robert Hyatt wrote: >>>>> >>>>>>On July 23, 2002 at 04:18:46, Bo Persson wrote: >>>>>> >>>>>>>On July 23, 2002 at 00:32:44, K. Burcham wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>Some say that Deep Blue could analyze 200,000kns in some positions. >>>>>>>> >>>>>>> >>>>>>>This is more the *average* speed of the system. I have seen figures of up to 1 >>>>>>>billion nodes per second, in favourable (for speed) positions. >>>>>> >>>>>> >>>>>>I have a paper written by Hsu and Campbell that says their peak speed during >>>>>>the 1997 match was 360M for a single move. Of course, the machine was capable >>>>>>of bursts to 1 billion nodes per second, which I am sure it hit at times >>>>>>since that only required that all 480 chess procesors be busy at the same >>>>>>instant. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>This doesn't say, of course, what the search speed would have been in your test >>>>>>>position. Could have been 150M nodes/s, could have been 950M nodes/s... >>>>>>> >>>>>>> >>>>>>>The comparison of speed is also somewhat flawed by the fact that Deep Blue was >>>>>>>explicitly designed to be fast (as in nodes per second), which most of the other >>>>>>>programs are not. >>>>>> >>>>>> >>>>>> >>>>>>I don't agree with that. DB was a two-fold design: (1) fast, due to special- >>>>>>purpose hardware (2) good, due to adding whatever they though necessary into >>>>>>the hardware. >>>>>> >>>>>>Software programs don't have the option (2) available to them, so to keep >>>>>>option (1) viable, they compromise. DB didn't have to. >>>>> >>>>>In order to have good evaluation function you need to know what is good. >>>>>Programmers today know better than what they knew in 1997. >>>>> >>>>>Uri >>>> >>>> >>>>No we don't. Chess has been chess for 100 years. 20 years ago we knew what >>>>we "needed". >>> >>>No we did not. >> >>OK... I will rephrase that. 20 years ago _I_ knew what we needed to do in >>the evaluation, but couldn't do due to cost. My evaluation for Cray Blitz >>is _very_ close to the evaluation I currently have for Crafty. The pawn >>stuff is effectively identical except for some endgame details. But weak >>pawns, passed pawns, outside passed pawns, candidate passed pawns, all that >>was in Cray Blitz in 1983. > >There are more things that are important in the middle game and >a lot of things are decided in the middle game. > >The main problem is not to define good evaluation for the endgame >but to define good evaluation for the middle game and I believe >that programmers do progress in that direction. You mix "programmers" with "micro programmers". IE in cray blitz I had a better king safety than I have today in Crafty, because finding all those attacks around the king is too expensive on the PC, while on the Cray it was easier using vectors. There were lots of other things, such as qualitative mobility that we did in Cray Blitz in a very inexpensive but workable way. It is too expensive to do it that way in Crafty... One day, perhaps. IE one day we might have real vector instructions on a PC, like intel did on the i860 family... >> >> >> >>> >>>Prorammers know better today because they have more experience in chess >>>programming relative to the experience that they had some years ago. >> >>Experience in "chess programming" is not the issue. "experience in chess" >>is more important... >> >> >>> >>>Finding the right evaluation and deciding what to evaluate is the problem. >> >> >>It never was the problem for me. I have _never_ had trouble finding new >>eval terms to try. I have had great trouble making the good ones affordable >>so that the could actually be used in the program... >> >> >> >> >> >>> >>>The evaluation of the top programs of today is better relative to the evaluation >>>of some years ago. >> >>Ask the top programmers these questions: >> >>1. When did you first evaluate passed pawn races? >> >>2. When did you first evaluate outside passed pawns? >> >>3. When did you first evaluate pawn majorities, candidate passed pawns, and >>the like? >> >>4. When did you start to be sophisticated in evaluating weak pawns, vs just >>simple rules for backward and isolated pawns? >> >>etc... >> >>I did all those 20+ years ago. I _know_ when micros started doing outside >>passed pawn code and it was fairly recently. Because when I first started >>doing it again in Crafty in 1994-1995 it used to beat the commercials in >>endgames right and left when that was important. > >I believe that the reason is simply that programmers >were afraid from bugs. I wasn't afraid of bugs, and I did them 20+ years ago. They were too expensive for the typical micro as everybody knew that a micro at one node per second was _not_ going to be viable. > >My opinion is that it is better to add knowledge slowly >to the evaluation and test to see if the change does >the thing better. That's the way I did it myself. > >If you do not do it, adding knowledge may be counter productive. >If you add knowledge about pawn structure your knowledge may be counter >productive if you add it in the wrong way and the problem may not be only bugs >but also wrong numbers. > >If the score for pawn structure is too high relative to the >mobility scores >the program with knowledge about pawn structure may sacrifice mobility >for pawn structure and play worse than the previous version >in part of the cases. So? Until you do the pawn structure code you are going to get shredded in endgames. Once you do, you at least have something to "balance" with other terms. Without it, you just have a huge hole that kills you. > >This is exactly what happened with a previous version of movei >and I decided to increase the score for mobility before >trying to evaluate pawn structure again so I still do not >evaluate isolated pawns or passed pawns. > >Adding a lot of evaluation in the last moment without testing >seems to me a not serious way to work. It isn't the way I work, I agree... > >If the deeper blue added a lot of knowledge then I wonder when they >had time to test every change. They obviously didn't because Hsu said much of their eval was not enabled for the 1997 match. They could have obviously made it much stronger with another year or two of tweaking, which would have happened had not Kasparov lost in 1997. > >If they tested and found that a lot of changes were >productive(without testing everyone of them) >then it is still possible that part of the changes >were counter productive and only the total result was positive. > >I was not impressed by deeper blue evaluation based >on watching the games. I was incredibly impressed. No micro of that day could come close to doing what they did. Micros regularly got eaten on ICC all the time. Go look up deep thought's record on ICC for example. And then consider the Kasparov matches. While they could have done better, they were most impressive in my opinion. They did win. They drew in endgames somethought were lost. Etc... > >Deeper blue could not see Qe3 in the pv in the second game and >it is not the only problem. Nobody else does for the right reason either... > >For example Kasparov could get advantage against deeper blue >with black by 1.e4 c6 2.d4 d6. > >Deeper blue still evaluated white as 0.18 pawns better at move 30 when it played >Ka1. > >Uri
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.