Author: Graham Laight
Date: 15:33:04 11/17/00
Go up one level in this thread
On November 17, 2000 at 14:27:08, Bruce Moreland wrote: >On November 17, 2000 at 11:31:47, Graham Laight 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 . >> >>Hi Walter, >> >>I've read the other threads in reply to your post, and I disagree with them >>profoundly. >> >>In fact, at the risk of being insulting (sorry chaps!), I think they're stupid. >> >>What is meant by "bean counting", as used by Chris Whittington (aka Joe Besogn) >>is evaluating a position by generating as many "nodes" in the "game tree" from >>this position as possible, and selecting the move that allows the least worst >>position to be achieved by the opponent. The emphasis is on generating as many >>Nodes Per Second (NPS) as possible. > >The emphasis is on beating humans and other programs. In order to achieve this, >the program must have a balance of tactical power and positional competence. > >This is a tradeoff that has practical consequences. If you make your eval >"better", which you'd think might make it play better positionally, it may be >forced into make positional concessions because it can't see tactical >consequences. But if your eval is too bad, you end up losing to tactics that >are over your horizon, because your position sucks. Generally I agree. But sometimes, you need an extreme case to make a point. In this case, the extreme case is human GMs, who can still beat the computers, despite having a very low NPS count. >Every programmer here, except the stupid ones, and I can't think of any of those >offhand, would cut the speed of his program by a factor of a thousand if he felt >that the strength of the program would increase. > >Another factor that is important is intelligence of search. If a program can do >the same thing it used to do, only 20% faster, it is usually at least a little >smarter. Likewise, if it can avoid doing pointless nodes in the tree, it is >also smarter, and this has nothing to do with the eval. Good point - I'll concede this fully. >The programmers who read this group are not attached to a particular philosophy >of chess programming. They are doing what they can do to win games. And I >include every programmer here, including Chris. Not even trying a little for exciting chess? :) >The design of these programs is based in pragmatism that comes from having to >actually solve a problem rather than talking about it. For me, what this thread is about at heart is "classification" - more so than how a program "should" be designed. Having written a program does not guarantee that you're going to be an impartial classifier of programs (IMHO). >>"Knowlwdge" (or at least what I think people should mean by "knowledge") is how >>much you know about something. It is estimated that human GMs know 50,000 >>discrete things (or recognise 50,000 different patterns) about chess. (Source: >>chess skills in man and machine). > >That is an ancient book, which discusses many ideas that have not made the >evolutionary cut in chess program design. It is an interesting book, but the >proper response to the 50,000 number is "so"? It might be an old book, but I've never seen any later work in empirically calculating the amount of knowledge a chess player has. For me, who's burning interest is in AI, the number is tremendously important, because it gives the best insight I've ever seen into how much "knowledge" is needed to be a human genius in a field. I believe that, to be a top genius in a common field of expertise, you need to know 50,000 things about it. 5,000 makes you an enthusiastic amateur. >>Where we have access to the source code for a program, we can make an estimate >>of the amount of knowledge that exists. I have done this for the evaluate.c >>function of Crafty.x (modified 6/1/00) which I downloaded from Dann Corbitt's >>site. I counted 150 discrete pieces of knowledge. I don't claim that number to >>be 100% accurate (I did the count quite quickly), but I do claim it to be of the >>right order of magnitude. > >There are more than 150 pieces of discrete knowledge in Crafty, depending upon >how you count. And that is not how they work, anyway. There are most likely >thousands of individual little micro-chunks, which working together try to guide >the program toward a good choice. Mine has ten or twenty thousand of these, a >lot of the evaluation info is generated at boot, rather than by hand, but I >don't claim it's smarter than Crafty. What does "at boot" mean? >And even if you count the knowledge in the endpoint eval, there is more >knowledge that is manifested through the addition of search. Search adds >concrete knowledge as well as intuitive knowledge. > >The programs can play as if they had knowledge that is not specifically coded >in, and which their programmer may not even possess. This apparent knowledge is likely to be a consequence of speed (aka the derogatory "bean counting"). In terms of classifying programs, if it appears to know something because of speed, but in reality it doesn't know that thing, we would have to count this as a case of "speed" rather than as a case of "knowledge". >>Now, if we accept that both the 150 and the 50,000 number are of the right order >>of magnitude, one would have to agree that the human GM is strongly "knowledge" >>based, wheras Crafty is strongly "bean counter" based. > >It is representative of all programs, not just fast ones. Yes - again using the extreme example to illustrate the point. >>What the other threads from your post are about, goodness only knows. > >I started the A-Z thread because I think it makes about as much sense as this >one. These programs can't be differentiated as to their approach, as long as we >don't know a lot about them. I think they are mostly very similar. This is probably true. However, birds are mostly similar compared to airplanes - but ornithologists still classify them. -g >bruce > >> >>-g
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.