Author: Tord Romstad
Date: 05:36:21 02/06/04
Go up one level in this thread
On February 06, 2004 at 08:13:44, Vasik Rajlich wrote: >On February 06, 2004 at 07:47:54, Uri Blass wrote: > >>On February 06, 2004 at 07:22:19, Tord Romstad wrote: >> >>>It is much more expensive than that. Remember that all squares are not >>>equally important, and that the bishop cannot safely move to all the squares >>>you attack. For each square the bishop attacks, you must see if it can >>>move there without getting captured, and consider how useful it is to be >>>able to move to this square. For each friendly pawn which obstructs the >>>bishop, you must consider how easy it is to advance this pawn. Most of >>>this is quite expensive to compute, and I have been forced to do some >>>dubious shortcuts and approximations in order not to slow my engine down >>>too much. Some day I should probably have a look at how Bob does this, >>>and see if there are some ideas there which I could use. >>> >> >>Bob does not do what you do in the evaluation and I doubt if what you do is >>needed. >> >>The fact that the bishop cannot move to some square does not prove that the fact >>that it looks at this square is not important because the opponent need >>something to prevent the bishop to go to that square so I think that simply >>counting the number of squares is a good approximation. You are right that attacking a square has some value even if the bishop cannot safely move there, but this is reflected in other components of the evaluation function. The attack contributes to the space evaluation for the side with the bishop, and may also restrict the mobility of the opponent. It seems unnatural to me to consider such attacks as part of the bishop's own mobility. >>Maybe if you replace your complicated mobility evaluation by simply counting the >>number of squares you may get better results because your program may be faster. >> >>Did you test simple mobility evaluation in games against your complex stuff to >>see that your complex stuff is better? I haven't tested it very thoroughly, and not recently. But I remember that my program looked less mechanical with a complex mobility evaluation, and as you know it is more important to me that my program looks good than that it wins games. :-) And as I said, I do some shortcuts to reduce the number of expensive calculations. I don't think I would speed up my engine much by switching to a mobility eval which just counts pseudo-legal moves. >In principle I agree with Tord. There's no doubt that when your bishop has >access to a square which is defended by the opponent's pawn, this is on average >less valuable than having access to a square which is not defended by an >opponent's pawn. The better the factors you take into account, the better your >program will play. > >However, it's very tough though to do this well. A few weeks ago I tried to >design a very simple blockade evaluator (ie can a blockade of a pawn be >maintained), and it's a really tough task. Practically speaking you can make >some guesses, based on some features, but then the risk is that you start >bloating your evaluation function with stuff that doesn't even work. Considering only pawns blocked by pawns isn't that hard. You can do some rather complex computations about the pawn structure and store the results in the pawn hash table, and hence get lots of information almost for free. Blocades by pieces is harder. When a pawn is blocked by a piece, it is sometimes difficult to know how hard it is to drive the piece away. Generally, I agree that it is tough to do it well, but the good thing is that it is not only tough, but also fun. :-) Tord
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.