Author: Don Dailey
Date: 22:08:19 01/14/98
Go up one level in this thread
Bob, I completely agree with you. I have a separate bonus for pushing passed pawns in my program and I also view the square of pawn as serving a separate purpose. I am just trying to figure out why it doesn't add more to the strength than it does. But you can't deny having an increasing penalty for distance from a passed pawn is very similar to a weak square of pawn algorithm in spirit if not purpose. Square of pawn is a "boolean" function and is on or off. The distance function is graduated and will also try to get a square of pawn although it doesn't understand when it achieves this and does not have the power to sacrafice for it. Its the old rule of 80/20 perhaps, my hypothesis is that some rule like distance to square in front of passer might give you 80% of the benefit. I do not disagree with you at all about the power of square of pawn though. You WILL make ugly blunders without it. I've noticed this 80/20 thing a lot in chess programming. There is no substitute for "doing it right" but if you cannot, then try to do it halfway! I don't mean "half assed" I mean try to cover the basics even if weakly. King safety is a good example of this. Until you've had the time to really work it out well, just putting in some basic principles like pawn shelter around the king and open file stuff will make a huge difference. You'll still succomb to sacrafices and have king safety problems but with 20% of the effort you can solve 80% of the problems. The last 20% will be the most difficult and this is what separates the men from the boys! Years ago before I knew anything about selectivity, me and Larry Kaufman were working it out for ourselves. We did not know about null move pruning and started playing with ways to determine an upper bound on the score. We figured out the static attack stuff on our own (others were also doing selectivity but we had no idea what they were doing. After having success with it we guessed that others must have made the same discoveries before us.) But during the process, one thing we tried was a simple margin against beta on the last ply. In other words if you are "well" above beta then you could stand pat (if you were not in check.) We did no attack testing at all! Now it turns out from extensive auto-testing that a very small margin is a huge improvement in quality and is clearly better than full width. No margin whatsoever is not bad but is slightly weaker than full width (fast as hell is it's only saving grace!) But why would 1/2 pawn margin work so well? There is no way pawn attacks rook would ever be covered by such a nonsense rule (and I agree its nonsense!) But it turns out that this was an 80/20 thing. Most of the time we would still avoid tactical blunders not because we saw it was a blunder, but just because the half pawn margin was enough to cover the typical situation which was usually a positional issue. And the extra speed DID allow us to see tactics the full width version would not have time to. We never kept this weak algorithm but went on to a nice SEE type of algorithm and did quite well with it in REX. So as I said in my post I think it could be a first come first serve type of thing (like mobility vs centralization where the first algorithm implemented looks the best because it improves the program the most because the 2nd one is partially redundant.) Yes it's silly not to have square of pawn, it's so cheap if you have pawn structure hash tables and one of the easiest ways to add rating points to your program. I hope this email is not used as an excuse for not having it, there is no excuse and this would be an error. - Don On January 14, 1998 at 09:47:01, Robert Hyatt wrote: >On January 14, 1998 at 09:08:45, Don Dailey wrote: > >>Hi Stuart, >> >>I'll bet square of the pawn differs significantly in what it adds to >>each program. I'm guessing that if you don't have good passed pawn >>heuristics it will make a bigger difference. When I specifically >>tested it a previous program it did not show up as being a big deal. >>But >>most programs probably have bonuses for getting the king closer to >>passed pawns (which mine does) and this may tend to serve the same >>function (but not nearly as precise.) >> >>But it's still very important to have this heuristic in my opinion. >>You WILL definitely lose and draw games you didn't need to. When it >>shows up it really does put your program in a different class and it's >>easy to implement the basic algorithm. There are some fine points you >>may want to cover later though like recognizing pawn races but you'll >>get 90% of the benefit with the simple version of square of pawn. >> >>I don't remember the test results specifically but I do remember it >>was enough to measure with little trouble. This implies at least 20 >>rating points but it could be somewhat more. But 20 rating points >>is a lot, a couple 20 pointers and you have a noticably better program. >> >> >>- Don >> >> > > >I view this as a totally different concept. Pushing passed pawns is one >thing. This is completely different. This idea comes into play when >(say) >both sides have passed pawns and perhaps a bishop vs knight or >something, >and you discover you can rip your opponent's knight and win one or two >pawns >as a result. Unless you have truly huge passed pawn push scores, your >program might do this, only to discover a few moves later that it can't >catch that pawn of the opponent's. Granted that with a decent hashing >algorithm, searching 15 or so plies is not too hard given enough time, >and >you ought to search this and find it. > >But suppose your q-search discovers this tactical trick near the end of >the search and that looks like the best score. So you win two pawns, >and >a few moves later discover uh-oh... > >So I don't depend on this to advance passed pawns... I depend on it to >help >me avoid trading into a material-up but dead lost ending. Without it I >found myself making lots of mistakes. This was one of the earliest >things >I added to Crafty. Fortunately it is basically "free" in terms of >computational costs, when using bitmaps. I'd bet that a program without >this will make huge mistakes in endgames, particularly at quick time >controls. You have to hope that a move made at the root, which leads to >an unstable position at the tip (where a pawn can run) leaves you an >option >to "bail out" later before you reach the critical (lost) position. If >it >does, you survive. If it is an early committment to an irreversible >plan, >you could be doomed. For the cost of the algorithm, it can't be wrong >to >do this. And it is actually easy to implement... just iterate over all >the >pawns to see if one side has a pawn that can't be stopped. If both do, >you >can get fancier as I have, and see which queens first, if one queens >with >check, or if one queens and simultaneously attacks the queening square >of the >other pawn, or if the latter is true does the king also defend the >queening >square so the pawn can promote anyway and draw? The more correct >answers, >the fewer mistakes you make. And the more games you don't lose to silly >mistakes...
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.