Author: Robert Hyatt
Date: 09:59:53 10/22/99
Go up one level in this thread
On October 22, 1999 at 12:27:39, KarinsDad wrote: >On October 22, 1999 at 11:57:01, Robert Hyatt wrote: > >[snip] >>> >>>If I had to guess, I would say that mobility is one out of several possible >>>causal factors in a good position. However, it usually requires other factors >>>such as material equality (or material advantage), square control, king threats, >>>etc. In and of itself, a mobility advantage does not guarantee a good position. >>>Just like in and of itself, a material advantage does not guarantee a good >>>position. Each factor that leads to a good position is a subset of all of the >>>factors and it is unlikely that any one factor takes precedence over all others. >>>However, any given factor does not have to be present in order to have a good >>>position (for example, you could be down a queen and about to checkmate or you >>>might have only one move on the board and about to checkmate). >>> >>>However, a chess program searches the graph and keeps moves which lead to >>>certain criteria and discards moves which do not. The fast searchers have a >>>criteria of material gain (for the most part). If you could add a LOT of >>>evaluation factors such as square control and mobility at an inexpensive cost >>>similar to material gain, I think you will lead the game away from hidden >>>pitfalls (beyond the event horizon) for you and towards hidden pitfalls for your >>>opponent (on average, I doubt any algorithm could do this for all relatively >>>equal positions) while at the same time, searching relatively deep. >>> >>>KarinsDad :) >> >> >>My very first evaluation (for crafty) was material + mobility. It played _very_ >>poorly. I added pawn structure. It _still_ played poorly. I came to the >>conclusion that mobility was an effect of, and not a cause of, a good position. >> >>Some common eval 'terms' enhance mobility. Rooks on open files. Outposts. >>Pieces not on the edge of the board. However, I have never been happy with >>mobility as any sort of 'important' eval term. I use it for bishops as it >>handles the 'good/bad' bishop case pretty nicely. But for other pieces, I don't >>do mobility at all. For the queen it is _particularly_ bad. > >I'll take your word on it. > >It doesn't make much sense to me, but then again, there are a lot of things in >this world that do not make sense to me, but that is the way they are. > >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... > >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... >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.