So far, we have represented WaterWorld boards using
propositions like

If writing a program about WaterWorld,
our program should reflect our conception of the problem.
However, as it stands, our conception corresponds
to having many many Boolean variables named *not* how
you think of the rules.
In other words, when explaining the game to your friend, you probably
say “if a location contains a 2,
then two of its neighbors are pirates”,
rather than droning on for half an hour about how
“if location

Moreover, the original rules only pertained to a
fixed-size board; inventing a new game played on a 50×50 grid
would require a whole new set of rules!
That is clearly *not* how we humans
conceptualize the game!
What we want, when discussing the rules, is a generic way to
discussing neighboring locations, so that
we can have one single rule, saying that if a (generic) location has
a zero, then any neighboring location is safe.
Thus, we allow the exact details of “neighboring location”
to change from game to game as we play on different boards
(just as which locations contain pirates changes from game to game).

In a program, you'd probably represent the board as a collection (matrix, list, whatever) of Booleans. In our logic, to correspond to this data structure, we'll introduce binary relations.

### Aside:

What, exactly, do we mean by “relation”?
We'll see
momentarily,
that we can represent

This relation "

### Exercise 1

We used a binary (two-input) relation to describe neighboring
locations.
How can we use a relation to capture the notion
“location

#### Solution

We'll use a unary (one-input) relation:

After defining relations and discussing their properties, we'll talk about interpreting logic formulas relative to particular relations.

Using relations gives us additional flexibility in modeling our domain, so that our formal logical model more closely corresponds to our intuition. Relations help separate the WaterWorld domain axioms (code) from the data, i.e., the particular board we're playing on.