Author: Uri Blass
Date: 16:00:57 11/16/00
Go up one level in this thread
On November 16, 2000 at 17:30:05, Bruce Moreland wrote: >On November 16, 2000 at 14:47:37, Uri Blass wrote: > >>On November 16, 2000 at 14:11:48, Amir Ban wrote: >> >>>On November 16, 2000 at 09:07:23, walter irvin wrote: >>> >>>>to me programs fall into 2 list bean counters and knowledge based . >>>>bean counters >>>>fritz >>>>junior >>>>nimzo >>>>lg2000a >>>> >>>>knowledge based >>>>shredder >>>>hiarcs >>>>rebel >>>>tiger >>>>diep >>>>crafty >>>>king >>>> >>>>now you would think that the knowledge based programs would destroy bean >>>>counters .but that is usually not the case .bean counters are some of the best >>>>and strongest .which makes me wonder if trying to put so much knowledge in a >>>>program really makes it better .i think that depth of search would count for >>>>more than knowledge . >>> >>>The term "knowledge based" is traditionally used in the field to excuse the poor >>>performance of a program by its programmer or its fans. In extreme cases (cf. >>>Botvinnik) it was used to excuse the failure of a program to play any games. >> >>I disagree >> >>Shredder,Rebel and tiger have good results and are considered by the poster as >>knowledge based programs. > >Amir is right, but look at this interesting problem. How much knowledge to >Rebel, Tiger, and Shredder have? How much does Junior have? What is knowledge >anyway? > >It all comes down to "brighteners", and whether you add them to your laundry >soap or not. Nobody knows what a brightener is, and even if you can define what >a brightener is, perhaps every else has them too. > >Of course nobody is going to define that, since nobody really knows what anyone >else does. > >Do you know for which which programs even know that their b2 bishop attacks the >g7 pawn, or whether they are blind to the c3/d4/e5 pawn chain in front of the >bishop? > >It's an artificial distinction. Perhaps at one point it would have been >possible to make a distinction by node rate, in order to claim that one program >is "thinking" about the positions more, since its node rate is low. But isn't >Tiger's extremely high? And doesn't Junior often play well positionally? > >So I think that what could be going on here is an argument about whether people >who start with the left foot can walk further than those who start with the >right foot. > >Anyone who has written a "knowledge" program that wants to tell us for sure >*why* it is a knowledge program is welcome to tell us why they have more feet >than the rest of us. I'd love to read that. But I don't believe anything that >I read on someone's box. > >>>The label gained acceptance because of the wide misconception that understanding >>>of positions necessarily comes at a great cost of speed. >> >>I am sure that it is possible to improve the evaluation without great loss of >>speed in nodes per second and this is the reason that I am against using the >>nodes per second to decide about the knowledge of the program, but I believe >>that part of the understanding cannot be done without great cost of speed. >> >>I prefer to talk only about the endgame because I agree that finding the right >>change in the middlegame's evaluation is not simple. >> >>I know that are known things in endgame books that my programs usually do not >>know(for example knowledge about the fact that KRPP vs KR is often a draw when >>the pawns are f and h). > >I think that this kind of information can be put into any program that isn't so >crazy about speed that they are no convenient hooks to attach this knowledge to. > >Even so, this is an interesting specific case. Which programs return a much >reduced score if you start out with pawns on f/h as opposed to pawns on e/g? >I'm talking about *significantly* reduced, not just 0.1 pawns, which might be >the result of having a center pawn (e) as opposed to a wing pawn (f). > >Even without specific knowledge of this ending, programs are pretty good at it. >Programs that have KRP vs KR will instantly detect won positions where they are >able to sacrifice a pawn to get into a won KRP vs KR, which is how won cases of >this ending are typically won, and they will put up stiff defense when they are >on the weaker side of this. The only problem is that they may make a poor >decision about when to enter into this ending. I agree that this is the only problem. Cases of wrong decision to go for KRPP vs KR are not common and this is worth maybe only 1/2 point elo but the point is that if you add many 1/2 elo from similiar rules you can get maybe 20 elo improvement assuming that you can solve the problems with no speed cost. If programmers can solve one of these problems every day without speed cost they can get 1/2 elo per day and it is clearly more than the average improvement of chess programs. I guess that the reason that programmers usually do not do it is the fact that it is not easy or impossible to solve these problems without paying in speed. 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.