Author: Robert Hyatt
Date: 22:10:36 07/17/02
Go up one level in this thread
On July 17, 2002 at 19:29:11, Russell Reagan wrote: >On July 17, 2002 at 14:53:18, Robert Hyatt wrote: > >>Here you are _badly_ wrong. If you look at my "trojan" code, particularly >>early versions, a couple of players found ways to beat me _still_. Crafty >>would not take the knight/bishop because of the big penalty. But they found >>ways to offer it _two_ pieces (one commonly a rook) and that was larger than >>my penalty and here I went again. > >It seems like that implies that I am not wrong, since here again you have >another exception to patch up your program with. > >>If you do something coarse and obvious, like black knight at a1/h1 = -1.0 >>or whatever, humans _will_ learn about it. And they _will_ exploit it if >>possible... > >Right, so by your method you have to patch up the program again, and again, and >again. > You call it "patching"... I call it "refining"... :) >>It has happened to me. I have seen it happen to _every_ program playing on >>ICC, be it commercial or amateur... > >Right, so why do you continue to put bandaids on it instead of working on a more >general solution? General solutions are certainly preferred. But not always possible, for reasons of computational cost or complexity. _any_ solution is better than none, so long as it is tuned reasonbly well. > This is how developing new theories works (which I'm sure you >know). You take the current theory with it's exceptions, handle the general >case, and then add in proper handling of the exceptions. At some point there >becomes a large number of exceptions, and continuing to patch up your program >with exception after exception and adding in little penalties for this or that >gets old. Eventually you have to develop a new theory that handles the special >cases properly. Isn't that how progress is acheived? That is certainly how my chess evaluation terms have evolved. However, I don't think that "general rules" exist for chess, other than for the coarsest of features. The rest are nothing but "special cases" and "exceptions to the general rules" and the like... > >Perhaps the human misplayed the trojan horse sac and isn't properly setup to >carry out the attack if the sac is accepted. In my case this was not an issue. I added the code because I already _knew_ that the human could prosecute the attack if the program took the piece. I knew it because I had dozens of games as evidence. So did all the other programs on ICC. > Your program shouldn't pass on the >sac just because you added in a penalty. There should be a method of determining >whether to take or not to take, not just a penalty to avoid it always. I think >the opening is another example. For the most part people use a piece square >table and give a knight on f3 a higher value, bonuses for castling, and so on. >The result is that the program controls the center and protects the king. I >think a better method would be to have your program do these things naturally. >For example, I think your program should castle because it feels the king is >safer after castling, not because you added a penalty for not castling. This is how castling is implemented in Crafty. It follows the GM principle "castle if you want to, or if you must, but _not_ just because you can." Crafty doesn't castle at first opportunity, nor does it castle in every game... >The >program should play to control the center because it has understanding of the >importance of that in the opening. For example, the correct move might be to >play Nh3 to protect the f2 pawn, but since your program gives a bonus to >controlling the center, it thinks d4 is best because that adds another attacker >to the center squares, and in addition to that the knight on g5 added to the >center control, so that was another factor that lowered the center control >portion of the evaluation. If the program understood why we are trying to >control the center in the first place, then perhaps it could correctly analyze >and evaluate. > >I think it's better to give the program understanding of why it's not good to >accept the trojan horse sac rather than giving it a pentaly for doing so. Would >you rather your child not steal because he understands why it's wrong to steal, >or because he'll get a spanking if he steals? That is all well and good, but the computer doesn't "understand" such general concepts. An evaluation term is very specific about some feature, rather than being something a human might use/understand. >If he understands why it's wrong >to steal, he's set for life (at least in that department). If he doesn't steal >because he fears punishment, then he will refrain from stealing only as long as >he sees potential punishment. The moment he is on his own without the threat of >punishment, he has no reason not to steal. > >Another example comes from Michael de la Maza's article at www.chesscafe.com >titled "400 Points in 400 Days." In it he says: > >"Which is the better way to learn about the benefits of castling: (A) Learn a >positional "rule" along the lines of "Castle early" or (B) Do ten tactical >problems in which a king in the center of the board gets mated? Clearly (B) is >superior. If you come across an opponent who fails to castle early and you know >(A) you'll be able to say: "Jeepers. My opponent doesn't know how to play chess >-- he didn't castle early." If you learned about the benefits of castling by >following option (B) you will know 10 concrete ways to punish the opponent." > >I think adding penalties for not castling or for taking the trojan sac is like >learning the general rule without having any understanding. Maybe you missed a >vicious attacking opportunity because your program decided to castle early >because you gave it a bonus for doing so, even though there was absolutely zero >threat to your king at that time. > >Russell Your idea simply doesn't work however. It requires that the program be able to see that it gets mated if it doesn't castle. That is beyond the ability of today's hardware. It is beyond the ability of 2010's hardware. That is why we have evaluation terms in the first place, otherwise we would need none. You would not worry about weak pawns if you can see that they are lost by searching. But we can't see that deeply, so instead we tell the program that in general, weak pawns are bad because you usually lose them way in the future beyond your search horizon. So don't create one and you won't have to worry about trying to save it later.
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.