Author: Bruce Moreland
Date: 13:27:57 04/27/00
Go up one level in this thread
On April 27, 2000 at 04:48:27, Dann Corbit wrote: >On April 27, 2000 at 04:42:50, Bruce Moreland wrote: >>On April 26, 2000 at 22:49:54, Peter Kappler wrote: >> >>>On April 26, 2000 at 21:36:46, Mark Longridge wrote: >>> >>>>Here it is: >>>> >>>>k7/8/PB6/PK6/P7/P7/P7/8 w - - 0 1 >>>> >>>> >>>>I think it could very well be a draw, as I don't see how to get the >>>>black king out of the corner. >>> >>>[D] k7/8/PB6/PK6/P7/P7/P7/8 w - - 0 1 >> >>Of course this is a draw, it's a well-known draw as long as the bishop doesn't >>control the queening square. If the bishop conrols the queening square, it's an >>easy win. Here is another one: >> >>[D] k7/1p6/1P6/8/8/8/8/K7 w - - 0 1 >> >>Put a white bishop anywhere on the board and this is a draw. > >Out of curiosity -- do you put things like this into your eval function, or just >hope that they fall out from basic principles or apply them at some heuristic >point or none of the above? I can easily dispatch based upon the type of material that is left. At program boot I set up a hierachy of functions that can return exact or heuristic values for various material configurations, in many cases based upon where the pieces actually are. I then figure out what endgame databases I have, and add these to my hierchary. What ends up happening is that I know if there is a endgame function chain at my current node. I can inquire of the root function as to whether the current position has an exact value or is unknown. If it's unknown, I continue through the chain, until I find a value or run out of functions. If I find nothing, I do the default eval. Depending upon where I am in the tree, I can handle the chain differently. Some of the functions, such as KR vs KR, are heuristic -- they return contempt factor regardless of whether one R can take the other. It would be dangerous to use these functions in the internal nodes, so I don't, I only allow that function to return a "known" value at the tips, where it is more likely to be accurate. Others can be used anywhere, since the values are accurate, and perhaps you can destroy a sub-tree. I like the idea of a hierarchy because you can fit available tables in on top of it without changing anything. You can also have several functions handling one material configuration, looking for different features. This sounds inefficient but it might make sense if each function can handle more than one configuration, and there end up being some that overlap. I'll catch the obvious Kmoch impotent pair case, and I'll catch the case where the weaker side has an extra pawn. There are freakish examples where this loses but I ignore those. I'll also catch this pawn ram case, which is a little frivolous, although my program did lose a half a point to it against an IM once. It costs me essentially nothing to check it. I can also catch various cool things like KRB vs KRP. Some programs know that KRB vs KR is drawn, but they think that the case where the weaker side has more material is better for the strong side. Mine doesn't. A case that prompted this involved a game in Jakarta 1996 where my program's opponent took a draw rather than sacrifice a piece in order to get KRPP vs KRN, with two dangerous pawns. I haven't checked, but it's possible that mine would go for it. A case where I use the hierarchy a lot is KBP vs KB. If I have the table, I simply use it. But if I don't, I'll check a couple of other things: 1) Pawn-down minor piece ending with king blockading pawn is drawn. 2) Opposite B pawn-down case is simply considered drawn at the tips, regardless of where the pieces are. I assume the B can control a square the pawn has to cross, and then it's simply over. So to answer your question, I try to craft various situations, and rely on general principles if I don't have a case crafted. I stole the idea of a dispatch table from Ernst. I can't remember if he has a hierarchy. If not, I thought of that myself, otherwise I stole it from him. bruce
This page took 0.01 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.