# Worksheet 1: Above and Beside

GeomLab uses the constants `man`

and `woman`

to represent stick-figure pictures of a man and a woman:

man |

woman |

Whenever an expression and a picture are shown like this, we mean
that GeomLab will show the picture as the value of the expression. You
should try to work out *why* the expression creates the picture
that is shown, and (if you like) check that it does so by typing the
expression into GeomLab.

Two operators that can be used to combine these images
are `$`

and `&`

. As illustrated in the two
examples below, `$`

means "beside", and
`&`

means "above":

man $ woman |

man & man |

What would `woman $ man`

look like? Sketch the picture
in the space below:

woman $ man |

Try typing `woman $ man`

into GeomLab and see if you
were right.

Geomlab has a number of other constant pictures, including
`tree`

, so typing the expression ```
(man $ woman) $
tree
```

produces the following image:

(man $ woman) $ tree |

What happens when you type `man $ (woman $ tree)`

into
GeomLab? Sketch here the image that is produced:

man $ (woman $ tree) |

You should find that both pictures are the same!

In the first example above, `(man $ woman)`

is worked
out (or *evaluated*) first, producing a picture of a man standing
beside a woman. Then the `$ tree`

part of the expression
puts a tree to the right of this picture.

Similarly, in the second example `(woman $ tree)`

is
evaluated first, producing a picture of a woman and a tree standing
next to each other. Then the `man $`

part of the
expression is evaluated, placing a man to the left of this
picture.

We can see that the same picture was produced in the two examples
above, so the two expressions we used are the same (or
*equivalent*). Since it's true for all pictures

, *p*

and
*q*

that*r*

(*p* $ *q*) $ *r* = *p* $ (*q* $ *r*)

we say that `$`

is *associative*. Since

is not always the same as
*p* $ *q*

, we say that *q* $ *p*`$`

is not
*commutative*.

You can try for yourself in GeomLab similar examples to those
above, but replacing `$`

with `&`

. You should
see that `&`

is also associative but not commutative.

Try typing `man $ (woman & tree)`

into GeomLab. You
should get an image that looks like this:

man $ (woman & tree) |

Something new is happening here. When GeomLab combines two pictures
using `$`

, their sizes are adjusted so that the pictures
have the same height, without changing the shape of either
picture.

In `man $ woman`

, they have the same height already, so
no adjustment is needed. However, in ```
man $ (woman &
tree)
```

, the picture `woman & tree`

is rather tall and
thin, so it must be reduced in size so that its height is equal to the
height of the other `man`

.

You will see that the picture produced above is different from the
one given by the expression `(man $ woman) & tree`

:

(man $ woman) & tree |

What happens if you put no brackets in? Try typing ```
man $
woman & tree
```

into GeomLab and sketch the image that results:

man $ woman & tree |

You should see that the expression `man $ woman & tree`

produces the same image as the expression ```
(man $ woman) &
tree
```

. This happens because a `$`

operation in an
expression is evaluated before an `&`

operation, just as
multiplication is evaluated before addition in an ordinary,
mathematical expression. For example, if you were asked to work out
the answer to `3 × 4 + 5`

, you would first work
out `3 × 4`

and then add `5`

to the
result, giving an answer of 17. We say that × *binds more
tightly than* +, and similarly that `$`

binds more
tightly than `&`

. When GeomLab works out what picture to
draw for `man $ woman & tree`

, it evaluates ```
man $
woman
```

first, and evaluates the `& tree`

part
afterwards.

Remember that although `$`

binds more tightly than
`&`

, *brackets will still be evaluated first*:

man $ ((man $ tree) & woman) |

Can you work out what expression gives this picture?

Now look at this picture:

(man $ tree) & (woman $ man) (man & woman) $ (tree & man) |

Both expressions give the same picture (try it!), so the expressions are equivalent.

If the pictures

, *p*

,
*q*

and *r*

all have the same
shape (as they do here), then the two expressions*s*

(*p* $ *q*) & (*r* $ *s*)

and

(*p* & *r*) $ (*q* & *s*)

produce the same picture.

But if the component pictures have different shapes, this is not
always true. For example, applying the rule to ```
((man & woman) $
man) & (woman $ tree)
```

we get the following pictures:

((man & woman) $ man) & (woman $ tree) |

((man & woman) & woman) $ (man & tree) |

We can see that the two pictures are not the same, since some of
the figures have been changed in size (or *scaled*)
differently. If you are good at algebra, you might like to try to work
out exactly when the equation

(*p* $ *q*) & (*r* $ *s*) = (*p* & *r*) $ (*q* & *s*)

is true for four pictures

,
*p*

, *q*

and
*r*

. A hint: it has to do with the ratios between
the widths and the heights of the pictures. The scaling rule of
GeomLab means that these ratios do not change when the pictures are
scaled up or down; both sides of the equation will give the same
result if the boundaries between the pictures meet in a point.*s*

In this sheet, we have seen that it makes to work with formulas whose
values are not numbers but pictures. We can have constants that stand
for fixed pictures, and we can have operators that combine pictures to
make new ones. Just as in ordinary algebra, it makes sense to think
about the relative priority of the operators: just as convention
dictates that multiplication is done before addition where they appear
together in a formula, we can make the convention that `$`

is done before `&`

.

In ordinary algebra, some equations are true no matter what values
we put for the variables they contain: for example, the equation
`a + (b + c) = (a + b) + c`

expresses the fact that addition
is associative. Similarly, we can look for equations that always hold
between formulas in our new kind of algebra.

Looking beyond our little world of pictures, there are many places in programming and computer science where the algebraic idea of having a set of values with operations on them is relevant. For example, tables of information in databases can be combined with algebraic operations that match the values in a column of one table with values that appear in a different column of another table. This is a good way of organising a database system so that people who use it in their programs are insulated from the way the data is stored.