 This lecture is part of an online number theory course, and will be about Euclid's algorithm. So Euclid's algorithm tells you how to find the greatest common divisor of two numbers. So I'll start by quickly reviewing that. So we recall that the notation A with a long vertical line B means A divides B. In other words, B is equal to NA for N an integer. So, for example, 2 divides 10, A divides 0 for any A, and 0 divides A only if A is equal to 0. Some other examples are 6 divides N times N plus 1 times N plus 2 for any integer N, and if N is odd, then 8 divides N squared minus 1. So if you haven't seen either of these before, I guess they're exercises or something. So the greatest common divisor, well, as you notice, greatest common divisor takes rather long time to write out, so it's usually abbreviated as GCD. An old name for this is Highest Common Factor, so in some old book you'll occasionally see H, C, F, which I'm not going to write out. And the greatest common divisor, the greatest common divisor of two integers A and B, is the largest integer, N, with N divides both of them. So N divides A and N divides B. Actually, there's a slight modification to this. If A equals B equals 0, then the greatest common divisor of 0 and 0 is 0, either by definition or there is actually a slightly complicated reason for doing this, which I won't go into. Now mathematicians being lazy quite often omit GCD, so they just write A, B for the greatest common divisor of A and B. And you may have noticed this is kind of ambiguous because this notation is used to mean lots of other things, so it's also an ordered pair and about 23 other things. And how do you tell when it means the greatest common divisor? Well, there's no good way. You just have to figure it out from context. Anyway, so for example, the greatest common divisor of 6 and 10, for example, which will be written as 6, 10, is just 2 because that's the largest integer dividing both 6 and 10. So we now come to the following problem, which is calculate the greatest common divisor of A and B. So that means the greatest common divisor, not the ordered pair. Well, I'm going to give about four methods and let's start off with the stupid method, which is just check all n with less than or equal to n less than or equal to the absolute value of A because greatest common divisor must be between these and see if n divides A and n divides B. And you just pick the biggest one with those properties. Well, this isn't quite as stupid as I claim. It does have some advantages. First of all, it's simple. It's easy to program. It obviously works because you just have to check a finite number of integers and pick the largest of them. In particular, it proves the greatest common divisor exists, which, okay, that's not terribly difficult, but it does want obvious big disadvantage. It's pretty slow because if A is quite large, then it's going to take ages to check all integers. Well, let's just check how slow. Well, the time taken is going to be, it's going to take roughly A steps, where each step is going to check to see whether some integer divides something else. Well, each step may take a fair amount of time, but we're just getting a rough estimate. So A is about 10 to the number of digits of A. So the time is going to be some constant to the number of digits of A. And this is the number of digits of A or the number of digits of B is roughly the length of the input to this algorithm. So when you're trying to assess how fast algorithms are, you usually try and figure out how long they take as a function of the input. So this algorithm takes exponential time because the time taken is an exponential function of the number of digits. And exponential time algorithms tend to be too slow to use in practice. So anyway, this gives us a target we've got to do better than. So we've now got to try and think of a better algorithm and we've got to beat exponential time. So let's try method two. We want to factor, we first factor A and B. So if I want to work out the highest, greatest common divisor of 24 and 60, for example, I do it like this. So I start by writing 24 is equal to 2 cubed times 3. It's factoring it into primes. We'll cover that later. And 60 is equal to 2 squared times 3 times 5. And now I can figure out the greatest common divisor as follows. I take the 2 cubed and the 2 squared and the greatest common divisor of those is obviously 2 squared. And then I take the 3 and the 3 and the greatest common divisor of these is 3 to the power of 1. And then I might take the, there's a sort of 5 to the 0 here and a 5 to the 1 here. And I take the greatest common divisor of these and this gives me 5 to the 0. So the greatest common divisor is 2 squared times 3, which is 12. And we can ask how fast is this? Well, that's actually a really tricky question because no one really knows how fast the fastest method of factoring is. This has been a subject of a lot of research. We can obviously factor in less than A steps. For instance, we only need to check devices up to the square root of A, but that's still sort of exponential in the length of A. And you can get factoring algorithms that are faster than exponential, but they're quite tricky. So let's just say it's faster than method 1, but still slow. At least it's slow, unless somebody thinks of a fast method for factoring. So it's actually a reasonably good method for small numbers A and B up to 100 or so if you're doing hand calculation. However, what happens if A and B are really large? For instance, maybe A and B both have a hundred digits. Can we find an algorithm that will do that in reasonably fast? Now, the answer is yes. We now come to Euclid's algorithm. So first of all, let's just recall division with remainder. This says if we've got two integers A and B and let's take A not equal 0 because if we try and divide by 0, we're going to run into problems. So we can write B is equal to Q times A plus R with naught less than equal to R is less than the absolute value of A. So here Q is the quotient and R is the remainder. Actually, Euclid stated division with remainder in a slightly different form. The problem was we have no problem writing down integers. You can write down an integer like 2, 3, 7, 1. But this is using the Indian notation for numbers which was only invented a few hundred years after Euclid. So you can also use it nicely for real numbers like 3.14159 and so on. And Euclid couldn't do that either. So what Euclid did to represent integers and real numbers was he represented either as the length of the line segment or sometimes as a ratio of the length of two line segments. And sometimes he uses the length of a line segment as a number and sometimes a ratio. And so there's not really an exact correspondence between Euclid's notation of numbers and hours, but most of the time this doesn't matter. So Euclid would state his division with remainder algorithm as follows. He would take a line segment and he would take another line segment and he would take several copies of the smaller line segment like this until they almost filled up the green line segment and the leftover bit at the end is going to be the remainder. So this line segment is A and this line segment is B and this remainder is R. So this was Euclid's geometric method of doing division with remainder and you notice he's not really doing... Well, he didn't really have a very clear concept of division. What he's really doing is repeated subtraction and looking at what's left over. It's not at all clear if Euclid had a concept of division of two real numbers. So now that we've got division with remainder, let's look at Euclid's algorithm and the easiest way to explain this is just to do an example. So let's find the greatest common divisor of 78 and 14 and what you do is you just repeatedly divide with remainder. So you say 78 is equal to 5 times 14 plus 8 and then you say 14 is equal to 1 times 8 plus 6 and then you say 8 is equal to 1 times 6 plus 2 and 6 is equal to 3 times 2 plus 0. So what's going on here is you see the remainder kind of gets shifted along like this and I can guess there as well. And when you get to a 0, we stop and this number here is then the greatest common divisor. So we can also write this out slightly more algebraically. So if you've got two numbers r0 and r1 and we want to find the greatest common divisor, what we're doing is we're just sending r0 equals q2r1 plus r2 and then we do r1 equals q3r2 plus r3 and r2 equals q4r3 plus r4 until we get to rn minus 1 equals qn plus 1 rn plus 0. And at that point, we stop and the greatest common divisor is this number here. Well, as I said, Euclid himself wouldn't have done that because he didn't have our algebraic notation. So instead, Euclid's version of this looks something like this. What you do is you take one line segment and we take a second line segment and then we subtract various copies of the second line segment from the first one and we have a little bit left over, which we can, let's call this the, it's my green pen gone, the green line segment and then you take the green line segment and you subtract a few copies of it from the orange line segment and you might get a pink line segment and then the pink line segment might exactly fill two copies of the green line segment and then the pink line segment is the greatest common divisor. So we should also check that this actually works. So we need to check several things. Does the algorithm, if any of you have ever done computer program, you have probably all come across the case where you write a program and it simply never stops because of some bug. So we need to check it stops. Well, yes, because the largest of our i, our i plus one is decreased each step. That means strictly decreased. So we're starting with positive integers and they're getting smaller and smaller and that can't go on forever. Does it stop with the right answer? Again, if you've done programming, you've all had the experience of a program stopping with the wrong answer. Well, that's quite easy because if you look at each step, you're taking a and b and you're writing, say, a is equal to q times b plus r and you're changing a b to br and then carrying on like this. And you notice that the greatest common divisor of a and b is the same as the greatest common divisor of b and r if a, b and r are related like this. So to each step, you're not changing the greatest common divisor and you eventually end up with rn and zero and the greatest common divisor of rn and zero is also rn. So it's easy to check that it does actually stop with the right answer. Then we should ask, how fast is it? Well, analysing this is quite tricky if you want to do it rigorously. In fact, this is a sort of classic example of an algorithm that people who study speed of algorithms study as a sort of warming up exercise. Well, let's just look at the worst case. Well, the worst case is when the numbers decrease as slowly as possible. So when you're writing a is equal to qb plus r, the worst case is it's reasonably plausible that it's going to be when q is equal to one. So an example of this, it might, if you're trying to find the greatest common divisor of 21 and 13, it might go 21, 13, 8, 5, 3, 2, 1, 1, 0. So each step you're only subtracting and not doing any, you're just subtracting one copy of each number from the previous one. Now you probably recognise these numbers there that just the Fibonacci numbers. I can't remember how to spell Fibonacci. So the Fibonacci numbers have a relation by fn equals fn minus one plus fn minus two. So each is the sum of the two previous ones. Well, how big are they? Well, you can see that fn is going to be at most two to the n. So the number of steps in the worst case is going to be at most about the log to base two of the absolute value of one of the numbers here. So it's some constant times the number of digits of A and B. This is a big improvement on the running time of the previous algorithms which instead of being sort of linear in the number of digits were exponential in the number of digits. So this is actually a really fast algorithm. Works fine even if A and B have, you know, you could do it by hand if A and B were several million, for example. Without too much trouble. Well, we can ask how fast is it if A and B are really large? Well, what do I mean by really large? Well, it might have thousands or even millions of digits. And we run into a problem here because the problem has a long division in it and long division is kind of slow and tedious. I'm not sure if long division is actually taught anymore in high school, but it was really tiresome to do by hand. Well, you say why is that a problem? I mean, you know, long division on a computer is now easy. Well, long division even on a computer is kind of tricky to get right. There was a case some time ago when Intel lost several hundred million dollars because there was a small and rather subtle bug in its double precision real division algorithm on one of its chips. Long division is, let's just sort of illustrate, long division is actually really hard to implement correctly. And how slow is it? Well, how difficult is it to do long division of B over A if A and B of N digits? The usual algorithm taught takes about the number of steps is some sort of constant times the number of digits or squared. And if you run this in, if you insert this into Euclid's algorithm, this means Euclid's algorithm is now going to take the number of digits of the input cubed. You're starting to get rather big, especially if you've got thousands of digits. Well, you can improve this. First of all, there are faster ways of doing long division. You can reduce this to the number of digits to the one plus epsilon if you're really clever and use things like the fast Fourier transform, which you won't go into. That's not actually necessary because you can rearrange Euclid's algorithm slightly so that instead of this taking the number of digits cubed, you can arrange that you're really only using the number of digits squared. I'm not going to discuss how you do that because there's actually a rather easier way that I'm just about to describe. Incidentally, one of the changes that computers have made to number theory is, first, we can do examples with really huge numbers of digits. No one in their right mind would try and multiply 2,000 digit numbers by hand, but it's really easy on a computer. The second is it's actually opened up a new area of number theory where you try and find fast algorithms for really large numbers and try and find the most efficient possible algorithm. The naive method for doing long division in Euclid's algorithm uses the number of digits cubed. There's an easy way to speed this up as follows. This is going to be method four. It's about as fast as Euclid's algorithm, but avoids having to handle long division. This is very simple. So step zero says if A or B is zero, stop because the greatest common divisor is going to be the other one of them. And then step one is take out all factors of two from A and B. And you may have to keep track of them because if you take out a factor of two from A and B, remember that's going to give you a factor of two and the greatest common divisor. And step two, you just subtract the smaller from the larger. So if we've got two numbers A and B with A less than B, then we replace them with the numbers A and B minus A. And then you go back to step zero. So that's really simple. In fact, if anything, it's even simpler than Euclid's algorithm because you're not doing division in any complicated way. You're just doing a single subtraction each step. And you may be dividing by two, but dividing by two on a digital computer is utterly trivial because you just have to shift everything right by one step. So let's just see an example of this. First, I want to find the greatest common divisor of 84 and 66. So first of all, neither is zero, so they don't stop. Now I take out factors of two. So 84 goes down to 21 and 66 goes to 33. And now I should make a note that there's a common factor of two in both of these. So let's just make a note to keep track of the factor of two. And now these are both odd. I've taken out all factors of two. So I just subtract one from the other and I get 21 and 12. And now one of these is even. So I take out all factors of two and I get 21 and three. And now I subtract, so I get 18 and three. And now one of these is even, so I get 9 and 3. And now I subtract again, so I get 6 and 3, and now one of them is even. So I get 3 and 3. Now I subtract, so I get 3 and 0. and this point we stop and the greatest common divisor is not quite three because I've now got to you remember we had this factor of two to keep track of so the greatest common divisor is three times two. Now you notice that's taking more steps in Euclid's algorithm, however each step is very much faster because instead of doing a long division which would be horrible if the numbers had thousands of digits we're just doing a subtraction. So the number of operations needed, well how many steps do you need? Well each step you're sort of dividing by two so the number of steps is not going to be much more than number of digits it's going to be some constant times the number of digits and then each step you need to do a subtraction and doing a subtraction is going to take about the number of digits so we should also multiply by the number of digits. So the total number of steps is some constant times the number of digits or squared which is better than the naive implementation of Euclid's algorithm. As I said Euclid's algorithm you can get to this if you're a little bit more careful about how you implement it. So if you're programming greatest common divisor on a digital computer you probably want to use some variation of method four if you're working for really big numbers and if you're using numbers that will fit in a single word of the computer then method three which is just the straightforward Euclid's algorithm is probably the best method. Okay next lecture we're going to give some applications of Euclid's algorithm in particular for solving linear diaphanetine equations.