Constructing The Integers 


Loosely speaking, here's the way we find the equivalence. If we allow the empty collection to be a thing, then the equivalence class containing the empty set is the zero. The equivalence class containing the set { 0 } is "1". We can add "1" to anything to get the next thing, and things just work. The definition of equality works the way we would expect, so everything just goes as we need.
So we can now do some algebra, should we feel so inclined. We can solve problems of the form:
You can see that this is pretty much exactly what we did last time. Last time we took collections and defined an equivalence relation, etc., etc. We'll do it again.
So here we go ...

Last time we declared things to be equivalent if there was a matching between them. This time I will declare that (a,b) is equivalent to (c,d) if a+d=b+c. Here are some examples. These are all equivalent:
These are equivalent:
I didn't choose those particular pairs for any special reason. There is no pattern to them, except that within a row, the pairs are equivalent.
Exercise:
But now I hear you cry:
In the 1400s Italy became the economic powerhouse of the world, because they worked out how to do accounting without having to do subtraction. Subtraction at that time was hard, really hard. To be honest, many people today have trouble with subtraction, and while today we can just reach for a calculator, they were hard to come by in the 1400s.
So how did they do this? What they did was keep two columns for the concept of "value". Things that were good, like cash and inventory, went into the first column. Things that were bad, like debt, went in the second. Thus when someone gave you $147, you would add 147 to the first column, and they, the person giving it to you, would add 147 to their second column. Two entries have to be made for each transaction, hence the phrase "Double Entry Accounting." (Yes, if you know about these things you'll know that this is not entirely true. Bear with me.)
So in modern parlance, the "value" of a company was given by the first column minus the second. If your entries were (147,236) then you were in trouble. If your entries were (236,147) then things were significantly better.
So for the pairs (a,b) and (c,d) the conceptual values are "ab" and "cd". If these are equal then the companies are of equal value. Thus (a,b) is equivalent to (c,d) if ab=cd.
Unfortunately we don't have subtraction, so we're not allowed to say that. However, we can turn it around:
Look familiar? This is the definition I gave just a few lines above. We can declare these pairs to be equivalent just by using addition  we don't need this complicated concept of subtraction.
Recap ...
Last time  This time  
Things we deal with:  Collections (sets)  Pairs of numbers 
Two things are equivalent if:  There's a matching  a+d = b+c 
So we have some things (pairs of numbers) and an equivalence relation. That means we have equivalence classes. We will call the collection of equivalence classes Z.
Last time we defined "addition" of two sets by taking the discriminated union. This time we define the sum of two pairs to be the pointwise of componentwise sum, so (a,b) + (c,d) = ( a+c, b+d ). Just add the numbers in each place.
Again, we take equivalence classes, and ask: Does this definition of addition on pairs transfer nicely to the equivalence classes? We want to know if we can use this definition of adding this pair to that pair to define a concept of adding equivalence classes.
You may wonder why this is interesting. Why is this new collection of equivalence classes (Z) different from our previous collection of equivalence classes (N) ? Or more useful?
Or even interesting?
It's time to introduce another concept  the function.
Detour through functions ...
We've already used functions, although not explicitly. It's worth introducing the concept with a little detail, and then putting more details in later.
So a function is like a black box that takes one (or more) things, and gives back something else. The things given back don't need to be different every time, but if you feed in the same things, you always get the same result.
The answers don't need to be the same type of thing as the inputs. For example, we could have a box that takes a car and gives back the registration number. Or we could have a box that takes a car and gives back the engine number. Or we could have a box that takes a book and returns the number of pages, or the number of words.
Or we could have a box that takes a set and gives back the number of things in it.
Or, given two sets, we could have a box that takes something from one of them, and gives back something from the other.
A little bit of notation. When we have a function, the collection of all possible things we can feed to it is called its "Domain." The collection of all things it actually does give as answers is called the "Image" of the function, sometimes also called the "Range." Any set that includes the Image can be called the CoDomain.

A little notation. We write things like f:A>B to mean that "f" is a function, "A" is the domain, and the value of "f" is always inside the set "B"  "B" is the CoDomain. It is not to be assumed that every element of "B" is hit by "f". Nor is it to be assumed that every element of "A" is taken to a different element of "B".
Hitting every element of the CoDomain, or only hitting things at most once, are both additional conditions that may or may not be satisfied by a particular function. There are special names that add these sorts of conditions to "f".
Further, being a bijection means that it's reversable. In particular, suppose f:A>B is a bijection. That means that for every b in B there is one and only one a in A that gets mapped to it. So f(a)=b.
Define g:B>A by g(b)=a.
That means that if you start with a, use f to send it over to B, then use g to send it back, you get back to where it started.
You can instead start with b in B, use g to send it over to A, then use f to send it back to B, and again, you're back where you started.
That's why a bijection is sometimes called a matching, and a Matching is what we used as our equivalence relation when we constructed the counting numbers.
Final point, suppose we have a function f:A>B that's an injection (so it's injective, defined above  go check) but not a surjection (so it's not surjective. Again, go check). We can convert f into a surjection by restricting ourselves to the Range (or Image) inside the CoDomain. Suppose B' is the image of f. We define a new function f ' that goes from A to B'. The new function f ' actually does exactly the same as the original function f, but f ':A>B' is a bijection (aka a matching).
Note: since f ' has a different CoDomain, technically it's not actually the same function. However, for each a in /A/, the function f ' takes the same value as f, so we often use the same name, and if the difference becomes important, we make it clear.
So why did I talk about functions? I'm going to take a function from the counting numbers (which are equivalence classes of sets using the equivalence relation "matching") into this new thing we've constructed (equivalence classes of pairs).
So for a number n in N, I need to say what it gets sent to in Z.
Remember, an element z of Z is an equivalence class of pairs of elements from N. So if I specify a pair of elements from N, I can then talk about the equivalence class it belongs to. And that's what I do.
In symbols:
N  T > Z ========== ============ n1  T > T(n1) = z1 .    n2  T > T(n2) = z2 +.    \/   T(n1)+T(n2) = z1+z2 <.   \_ These two things  \ / should be equal. '> n1+n2  T > T(n1+n2) <'
The point is that it doesn't matter what route you take to get to the endpoint, you should get the same answer.
If this happens then we say that the function T "respects" or "preserves" the addition operation. In a very real sense, the image of T (that is, the things that get hit by the function T ) is a copy of N. We have found, inside Z, a copy of N.

Given a pair of numbers, (a,b), let's call its equivalence class E( (a,b) ).
It turns out that E(0,0) has a very special property: when you add it to z, the answer is z.

That means that E(0,0) behaves exactly like our ordinary 0 in the numbers that we are so familiar with.
Now consider E(3,5), and add it to E(5,3). The answer is E(8,8), and (8,8) is equivalent to (0,0), so that means that:
Now we can solve the equation:
*x + E(8,0) = E(5,0)
By our rules we know that E(5,0) = E(8,3), because (5,0) is equivalent to (8,3), because 5+3=0+8. So the equation we want to solve is:
So, to summarise ...
The method above is not the only way to construct something that behaves as the integers should, starting with only the counting numbers. The usual way of writing integers suggests another way.
Say that an integer is either a counting number (0,1,2,...) or a nonzero counting number with "" stuck in front of it (1,2,...); and then define arithmetic operations on these things case by case. So, for instance, to define addition on the integers we need to consider the following cases:

Which is better? Most mathematicians would choose the first way.
It's harder to understand at first, but the ideas it uses
ordered pairs, equivalence relations, etc. turn out to be useful
throughout mathematics. (For instance, we can use a very similar idea
for constructing the rationals.) And the payoff in simplicity
and elegance is considerable.
