Author: Robert Hyatt
Date: 13:48:56 10/22/99
Go up one level in this thread
On October 22, 1999 at 13:23:27, KarinsDad wrote: >On October 22, 1999 at 12:59:53, Robert Hyatt wrote: > >[snip] >>> >>>To me, it is a matter of possibilities. If I attempt to minimize the mobility of >>>my opponent's pieces (i.e. prophylactic move) while trying to maintain or >>>increase my own mobility, it would seem that I should be increasing my >>>possibilities later in the game. >> >> >>Sure.. but think about this: You are attacking your opponent's king, and you >>are just about to break through. All your pieces are on the kingside, which >>means their mobility is drastically reduced since they are in each other's way. >>So to increase your mobility, drastically, you swing your queen over to the >>other side of the board where it now is basically unrestricted in the number >>of moves it has. Of course, it could just as well be moved to an adjacent board >>that has nothing to do with this game. But you do get a lot of mobility by >>doing so. :) >> >>That is the kind of thing I saw. And the inverse seems to be true too. If you >>have little mobility, you are in trouble. But if you have a lot of the wrong >>kind of mobility, you are in deeper trouble. IE a centralized queen, bishops >>and knights, but your king is mated in the corner while you have all of that >>mobility for the rest of the pieces. I don't think 'mobility' tells much >>by itself... > >I agree. I am not trying to say that safe square mobility in and of itself is a >good factor to measure. I am trying to say that it is an easy factor to acquire. > >I haven't done any calculations on it in real positions (so this is all opinion >at this point and probably not worth the bits it takes to store it), but I would >guess that safe mobility would be worth about a pawn. By this, I mean that if >one side has a LOT of safe mobility in a relatively stable position and the >other side just has virtually no safe mobility, the one side has a pawn >advantage over the other. > >Now, of course, you have to take into account a bunch of other factors such as >what type of position you are in. For example, a closed pawn structure might >minimize the mobility advantage, maybe even to the point of not calculating it. > >>> >>>However, the program has to have other factors as well. Code to prevent moves >>>such as Rd1 xxx Re1 yyy Rd1 zzz Re1, etc. Evaluation terms for material gain; >>>for not moving pawns in front of the king during the middlegame, but allowing >>>them to move in the endgame; for square control (which helps in calculating safe >>>mobility); in king safety; etc., etc., etc. >>> >>>Now by mobility, were you considering "safe mobility" (i.e. a square is only >>>safe if your opponent cannot win your piece by moving it there, similar to a >>>SEE) in your early versions of Crafty or "any mobility" (i.e. the piece can >>>legally move there)? >> >>I tried both. Early on I had both attacks_from[sq] and attacks_to[sq] so >>that it was easy to find out which pieces were attacked by pawns, by >>knights/bishops, by rooks, and finally by queens. Then the respective mobility >>masks were first reduced by removing squares attacked by lesser pieces. I also >>tried 'psuedo-mobility' which is simpler. Both seemed fairly equal. And both >>seemed fairly ineffective. >> >> >> >> >>> >>>Also, in answer to your a4 move, the "do not move edge pawns in the opening" >>>guideline code should counteract any gain in mobility. However, I have not >>>written any "guidelines" on this type of code yet due to the difficulty in >>>determining when such a guideline should be in effect vs. when it should not. My >>>thinking is that I will add this type of guideline to my plan postprocessor as >>>opposed to the eval function. >>> >> >>I don't know of such a 'guideline' in chess. moves like a6/b5 are standard >>opening fare in many opening systems.... and h3/h6/a3/a6 are common in almost >>all opening systems... But when you do this, remember that you are adding a >>term that 'nullifies' mobility. And when you handle all of the most common >>exceptions, I bet you don't have much of a 'mobility' term left. Certainly >>not for the queen, because if you do queen mobility, as a human I am going to >>give you great difficulty since it becomes easy to lure the queen toward all >>that mobility, and away from where it is needed for attack/defense. That is >>one reason the 'trojan horse attack' works so well... the first step is to give >>up a pawn on the queenside to lure the queen away from defending your king... > >Yes, but a4, a5, h4, and h5 are not that common (yes, a4 in Queen's Gambit >Accepted, yes, h4/h5 in the French), but the "guideline" can take into account >specific openings. I try to take to heart the preaching in "My System" by Nimsovich: _EVERY_ pawn move is _BAD_. Some are less bad than others, and some are needed to parry threats by the opponent. But since they can never be 'taken back' they should only be played when it is absolutely certain that the move is required. IE to not let the opponent stuff pawns at a4/b4/c4 and create a passed pawn 'sneaker'. But if I was doing mobility, it would be working against that evaluation code, because you have to push pawns to increase mobility. > >And, if the guideline is not done in the eval, then you are not nullifying >mobility. For example, say you do a standard move generation where a4/a5/h4/h5 >are practically the last moves ever generated. Then, in a cutoff situation, you >know that they were not even considered. If a4/a5/h4/h5 are handled by a plan >postprocessor (as in my code), then these types of moves modify the decision >making process, not the mobility evaluation. > >I think common themes like the "trojan horse attack" and the "bishop takes edge >pawn" have to be specifically handled in order to avoid them. > >At this point, most of this is speculation. I will take your words into >consideration and look to see if my results match yours. If so, I may discard >the idea of safe mobility (however, I will probably just keep the code in a >conditional compile in order to add it back in every once in a while to see if >some other factor can be positively influenced by it). > >KarinsDad :)
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.