Author: Robert Hyatt
Date: 05:09:59 01/15/98
Go up one level in this thread
On January 15, 1998 at 01:08:19, Don Dailey wrote: >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. > I wouldn't disagree at all, other than these things address two distinctly different problems. One is positional in nature, the other is tactical. I depend on this code to avoid making an elementary tactical mistake, such as the one NuChess made against us in 1984. I rely on the "weak version" to provide correct endgame play. But I'm more worried about trading into a lost ending where a pawn scampars down and can't be caught. >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! I agree. I did the two connected passers on the 6th code, and it worked well. Then I found exceptions and continued to refine it to the point I have now reached where I don't see it fail very often. But it is never perfect, although "square of the pawn" can be. > >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
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.