Author: Don Dailey
Date: 10:09:26 06/27/98
Go up one level in this thread
On June 27, 1998 at 12:28:16, Bruce Moreland wrote: > >On June 27, 1998 at 09:53:00, Vincent Diepeveen wrote: > >>No theoretical bullshit, it's clear that all evidence shows how little >>knowledge DB has, now it's time to show the audience why it's >>so hard for low rated people to program chessknowledge. > >On your web page you once said that you thought that the average chess >programmer's chess knowledge was about 1400. > >I think you are off by about 600 points, I think I am typical at about 2000. > >But I have also studied chess as it relates to computers. Whether or not this >has helped my over the board play, I do not know, but I am quite happy >discussing rams, duos, dispersion, distortion, and yes, majorities. > >Hsu is weaker than 2000 as far as I know, but he didn't write DB's eval code, >Murray Campbell did, in consultation with players stronger than Murray, and as >far as I know, Murray is pretty strong. > >>I doubt that Hsu has ever heart of the word 'pawn majority'. >>I dropped some day this word among some chessprogrammers, >>and they all didn't even know what the word means. Because being >>the programmer he's the one who needs to implement so he needs to >>be the one that must exactly understand what it is and what it is not. > >The stronger ones probably do. > >But even if they don't, it really doesn't matter *that* much, I think. I don't >have pawn majority code in mine. It is pretty complicated to write, and even >when I hash it it takes a lot of time to execute. It may not be as bad as you think. We have a pretty simple algorthm for this that is not time consuming to exectute and it pretty accurate. One point to make is that we really identify "candidate passers" which is a somewhat simpler task to perform. In many cases each side has one and they cancel out, but the end result is that a majority will always stand out. For most programs it is trivial to identify "unopposed pawns" and once you have these you need to count pawns on neighboring files for each side. There are a couple tricky cases but once you work them out you will end up with a very useful term in your program. Larry careful worked out the rules long ago and we are pretty happy with the simple implementation we have. >I get burned from not having it, I am sure. I often have problems with >opponents having distant passers, but the cases where it is a majority that >causes problems by itself aren't that common, it seems, or at least they get >covered by other things. I think this is actually a big problem in computer chess. Many terms are partially covered by many other terms! There is a lot of overlap and getting things just right is a delicate balancing act. Fix one problem and create a new one. I believe getting these terms right can improve a program a whole lot more than adding more terms. Unfortunately I'm not sure how to do this! - Don > >bruce
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.