Appendix G: Tracing Mobility through Squares Attacked by both Friendly
and Enemy Pieces
"Even with a coherent and usable set of goals to guide strategic planning, the process is still difficult
because alternatives have to be evaluated in the face of uncertainty." - Alan Gropman, Long-Range Planning (1979)
This subject is important considering the fact that it will often
be the case that it will not be clear whether we can "safely" trace piece mobility through squares attacked by both friendly
and enemy pieces.
The first thing we need to do is to count up how many mobility squares and pieces attacked are involved
if the piece is "allowed" to trace mobility through the candidate square. If the answer is that "not much" mobility/ attacked
pieces/ defended pieces result, then it may not matter what method we use to determine the "allowability" of such mobility
in the evaluation function.
If mobility through the square in question would permit significant pressure, we might consider
a simple algorithm that simply counts the number of attackers and the numbers of defenders. If there are
and equal or greater number of friendly pieces "defending" the square in question, then we might allow the piece
in question to trace mobility through the square in question and put pressure on the pieces in the squares beyond.
A more complicated algorithm will consider, in addition to the above information, the lowest value
enemy "attacker". We might consider a "speculative exchange of pieces" on the square in question, involving available
attackers and defenders.
When estimating the positional pressure of the pieces, we might just consider the "upper bound"
for piece mobility (no restrictions placed) and the "lower bound" (mobility denied for any square attacked by an enemy piece)
and just split the difference, or take some fractional value of "upper" and "lower" bounds.
Whatever method we use will have to be tested. One of these above methods will perform better than
the others in a sample tournament of a few hundred games (at a fast time control), and perhaps we should make our decision
on which algorithm to use based on the performance results from such a tournament. Our task now becomes one
of creatively generating strategies for resolving such conflicts (when they occur) and generating performance test results.
We might get best results by assuming that the end-point "leaf" positions in our search tree are
absolutely quiescent, in that there are no pins, forks, or other tactical tricks lurking. It might be, however, that
we should consider the presence/ absence of a small number of these tricks when scoring the position. There might be an easy
way to identify positional "cues" which indicate that taking the computing time to identify and score these tactical measures
has a performance "payoff".
Another idea here is to use probability. When we have a case where we are tracing mobility for our
knight and we come up to a square attacked by an enemy knight. We might ask, "in a database of 1000 games, what is the probability
that a knight can move safely through a square attacked by an enemy knight?" We might find that the probability in this case
is 50%. We would then use the 50% to modify the bonus given to this piece for mobility through the square in question. We
would then need a database of a large number of games, and a processing run which computes the probabilities of pieces being
able to safely trace mobility through certain squares attacked by enemy pieces. The general goal here is to estimate how much
the enemy knight constrains the movement of our own knight.
Performance testing will again tell us the method(s) that we should adopt in our proposed heuristic.
