Appendix C: Database of Future Mobility

Appendix C: "Database of Future Mobility" Further Explained

Ok - this idea has to do with the move maps that I discussed on the randomvisitor forum at chessgames.com April 12 and 13, 2006. This is an advanced idea dealing with data structures so if you don't get this don't worry - the intended audience is computer programmers who are used to dealing with complicated data structures.

Let's say we have this position:

#	direction	squares	source	contents	board
1	upper left	c6, b7, a8	d5	empty	current
2	upper right	e6, f7, g8	d5	empty	current
3	lower left	c4	d5	Black knight, capturable	current
4	lower right	e4, f3, g2, h1	d5	empty	current

Now we might want to regenerate this simple 1st order mobility table if the black Knight on c4 moves to b2. So we look at our table and we see that c4 is on our Bishop's mobility map under "Lower Left Arm". We only have to recompute the Lower Left Arm of the Bishop's mobility, The other "arms" stay unchanged. What if we move the pawn up to e6? Well, e6 shows up on our Bishop's mobility map for the upper right arm. We would have to recalculate that, but the rest of the mobility map remains unchanged. Now, what if the bishop moves from d5 to f7? Well, the e6 pointer moves from the Upper Right Arm to the Lower left arm, which also now has an d5 entry, and we have to recalculate the Upper Left Arm and the Lower Right Arm of the mobility table, but the rest of the Bishop's mobility data structure stays the same.

The point here is that calculating future mobility maps for pieces doesn't have to be an excessive exercise because most of the future mobility data stays the same from the previous move. If we set up our data structure correctly, we will immediately know what part of our mobility maps we have to recompute.

This is in response to arguments that calculating "future mobility" is too processor intensive to work. We would actually reuse most of the mobility information for each piece, so this saves processor time. This example only deals with one level of mobility, but some will see how I plan to use recursion to extend this idea to mobility 3 moves into the future (See Example 1 below).