Author: Uri Blass
Date: 15:32:13 07/23/02
Go up one level in this thread
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. > > > >> >>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. 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. 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. 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. If the deeper blue added a lot of knowledge then I wonder when they had time to test every change. 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. Deeper blue could not see Qe3 in the pv in the second game and it is not the only problem. 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.