4B: Generic Operators

• Download this transcript - PDF (English - US)

[MUSIC-- "JESU, JOY OF MAN'S DESIRING" BY JOHANN SEBASTIAN BACH]

PROFESSOR: So far in this course we've been talking a lot about data abstraction. And remember the idea is that we build systems that have these horizontal barriers in them, these abstraction barriers that separate use, the way you might use some data object, from the way you might represent it. Or another way to think of that is up here you have the boss who's going to be using some sort of data object. And down here is George who's implemented it. Now this notion of separating use from representation so you can think about these two problems separately is a very, very powerful programming methodology, data abstraction.

On the other hand, it's not really sufficient for really complex systems. And the problem with this is George. Or actually, the problem is that there are a lot of Georges. Let's be concrete. Let's suppose there is George, and there's also Martha. OK, now George and Martha are both working on this system, both designing representations, and absolutely are incompatible. They wouldn't cooperate on a representation under any circumstances.

And the problem is you would like to have some system where both George and Martha are designing representations, and yet, if you're above this abstraction barrier you don't want to have to worry about that, whether something is done by George or by Martha. And you don't want George and Martha to interfere with each other. Somehow in designing a system, you not only want these horizontal barriers, but you also want some kind of vertical barrier to keep George and Martha separate.

Let me be a little bit more concrete. Imagine that you're thinking about personnel records for a large company with a lot of loosely linked divisions that don't cooperate very well either. And imagine even that this company is formed by merging a whole bunch of companies that already have their personnel record system set up. And imagine that once these divisions are all linked in some kind of very sophisticated satellite network, and all these databases are put together. And what you'd like to do is, from any place in the company, to be able to say things like, oh, what's the name in a personnel record? Or, what's the job description in a personnel record? And not have to worry about the fact that each division obviously is going to have completely separate conventions for how you might implement these records. From this point you don't want to know about that.

Well how could you possibly do that? One way, of course, is to send down an edict from somewhere that everybody has to change their format to some fixed compatible thing. That's what people often try, and of course it never works. Another thing that you might want to do is somehow arrange it so you can have these vertical barriers. So that when you ask for the name of a personnel record, somehow, whatever format it happens to be, name will figure out how to do the right thing. We want name to be, so-called, a generic operator. Generic operator means what it sort of precisely does depends on the kind of data that it's looking at.

More than that, you'd like to design the system so that the next time a new division comes into the company they don't have to make any big changes in what they're already doing to link into this system, and the rest of the company doesn't have to make any big changes to admit their stuff to the system. So that's the problem you should be thinking about. Like it's sort of just your work. You want to be able to include new things by making minimal changes.

OK, well that's the problem that we'll be talking about today. And you should have this sort of distributed personnel record system in your mind. But actually the one I'll be talking about is a problem that's a little bit more self-contained than that. that'll bring up the issues, I think, more clearly. That's the problem of doing a system that does arithmetic on complex numbers. So let's take a look here.

Just as a little review, there are things called complex numbers. Complex number you can think of as a point in the plane, or z. And you can represent a point either by its real-part and its imaginary-part. So if this is z and its real-part is this much, and its imaginary-part is that much, and you write z equals x plus iy.

Or another way to represent a complex number is by saying, what's the distance from the origin, and what's the angle? So that represents a complex number as its radius times an angle. This one's called-- the original one's called rectangular form, rectangular representation, real- and imaginary-part, or polar representation. Magnitude and angle-- and if you know the real- and imaginary-part, you can figure out the magnitude and angle. If you know x and y, you can get r by this formula. Square root of sum of the squares, and you can get the angle as an arctangent.

Or conversely, if you knew r and A you could figure out x and y. x is r times the cosine of A, and y is r times the sine of A. All right, so there's these two. They're complex numbers. You can think of them either in polar form or rectangular form. What we would like to do is make a system that does arithmetic on complex numbers. In other words, what we'd like-- just like the rational number example-- is to have some operations plus c, which is going to take two complex numbers and add them, subtract them, and multiply them, and divide them.

OK, well there's little bit of mathematics behind it. What are the actual formulas for manipulating such things? And it's sort of not important where they come from, but just as an implementer let's see-- if you want to add two complex numbers it's pretty easy to get its real-part and its imaginary-part. The real-part of the sum of two complex numbers, the real-part of the z1 plus z2 is the real-part of z1 plus the real-part of z2. And the imaginary-part of z1 plus z2 is the imaginary part of z1 plus the imaginary part of z2. So it's pretty easy to add complex numbers. You just add the corresponding parts and make a new complex number with those parts.

If you want to multiply them, it's kind of nice to do it in polar form. Because if you have two complex numbers, the magnitude of their product is here, the product of the magnitudes. And the angle of the product is the sum of the angles. So that's sort of mathematics that allows you to do arithmetic on complex numbers.

Let's actually think about the implementation. Well we do it just like rational numbers. We come down, we assume we have some constructors and selectors. What would we like? Well let's assume that we make a data object cloud, which is a complex number that has some stuff in it, and that we can get out from a complex number the real-part, or the imaginary-part, or the magnitude, or the angle.

We want some ways of making complex numbers-- not only selectors, but constructors. So we'll assume we have a thing called make-rectangular. What make-rectangular is going to do is take a real-part and an imaginary-part and construct a complex number with those parts. Similarly, we can have make-polar which will take a magnitude and an angle, and construct a complex number which has that magnitude and angle.

So here's a system. We'll have two constructors and four selectors. And now, just like before, in terms of that abstract data we'll go ahead and implement our complex number operations. And here you can see translated into Lisp code just the arithmetic formulas I put down before. If I want to add two complex numbers I will make a complex number out of its real- and imaginary-parts. The real part of the complex number I'm going to make is the sum of the real-parts. The imaginary part of the complex number I'm going to make is the sum of the imaginary-parts. I put those together, make a complex number. That's how I implement complex number addition.

Subtraction is essentially the same. All I do is subtract the parts rather than add them. To multiply two complex numbers, I use the other formula. I'll make a complex number out of a magnitude and angle. The magnitude is going to be the product of the magnitudes of the two complex numbers I'm multiplying. And the angle is going to be the sum of the angles of the two complex numbers I'm multiplying. So there's multiplication.

And then division, division is almost the same. Here I divide the magnitudes and subtract the angles.

Now I've implemented the operations. And what do we do? We call on George. We've done the use, let's worry about the representation. We'll call on George and say to George, go ahead and build us a complex number representation. Well that's fine. George can say, we'll implement a complex number simply as a pair that has the real-part and the imaginary-part. So if I want to make a complex number with a certain real-part and an imaginary-part, I'll just use cons to form a pair, and that will-- that's George's representation of a complex number.

So if I want to get out the real-part of something, I just extract the car, the first part. If I want to get the imaginary-part, I extract the cdr. How do I deal with the magnitude and angle? Well if I want to extract the magnitude of one of these things, I get the square root of the sum of the square of the car plus the square of the cdr. If I want to get the angle, I compute the arctangent of the cdr in the car. This is a list procedure for computing arctangent. And if somebody hands me a magnitude and an angle and says, make me a complex number, well I compute the real-part and the imaginary-part, or our cosine of a and our sine of a, and stick them together into a pair.

OK so we're done. In fact, what I just did, conceptually, is absolutely no different from the rational number representation that we looked at last time. It's the same sort of idea. You implement the operators, you pick a representation. Nothing different.

Now let's worry about Martha. See, Martha has a different idea. She doesn't want to represent a complex number as a pair of a real-part and an imaginary-part. What she would like to do is represent a complex number as a pair of a magnitude and an angle. So if instead of calling up George we ask Martha to design our representation, we get something like this. We get make-polar. Sure, if I give you a magnitude and an angle we're just going to form a pair that has magnitude and angle.

If you want to extract the magnitude, that's easy. You just pull out the car or the pair. If you want to extract the angle, sure, that's easy. You just pull out the cdr. If you want to look for real-parts and imaginary-parts, well then you have to do some work. If you want the real-part, you have to get r cosine a. In other words, r, the car of the pair, times the cosine of the cdr of the pair. So this is r times the cosine of a, and that's the real-part. If you want to get the imaginary-part, it's r times the sine of a.

And if I hand you a real-part and an imaginary-part and say, make me a complex number with that real-part and imaginary-part, well I figure out what the magnitude and angle should be. The magnitude's the square root of the sum of the squares and the angle's the arctangent. I put those together to make a pair. So there's Martha's idea.

Well which is better? Well if you're doing a lot of additions, probably George's is better, because you're doing a lot of real-parts and imaginary-parts. If mostly you're going to be doing multiplications and divisions, then maybe Martha's idea is better. Or maybe, and this is the real point, you can't decide. Or maybe you just have to let them both hang around, for personality reasons. Maybe you just really can't ever decide what you would like.

And again, what we would really like is a system that looks like this. That somehow there's George over here, who has built rectangular complex numbers. And Martha, who has polar complex numbers. And somehow we have operations that can add, and subtract, and multiply, and divide, and it shouldn't matter that there are two incompatible representations of complex numbers floating around this system.

In other words, not only like an abstraction barrier here that has things in it like a real-part, and an imaginary-part, and magnitude, and angle. So not only is there an abstraction barrier that hides the actual representation from us, but also there's some kind of vertical barrier here that allows both of these representations to exist without interfering with each other.

The idea is that the things in here-- real-part, imaginary-part, magnitude, and angle-- will be generic operators. If you ask for the real-part, it will worry about what representation it's looking at.

OK, well how can we do that? There's actually a really obvious idea, if you're used to thinking about complex numbers. If you're used to thinking about compound data. See, suppose you could just tell by looking at a complex number whether it was constructed by George or Martha. In other words, so it's not that what's floating around here are ordinary, just complex numbers, right? They're fancy, designer complex numbers.

So you look at a complex numbers as it's not just a complex number, it's got a label on it that says, this one is by Martha. Or this is a complex number by George. Right? They're signed. See, and then whenever we looked at a complex number we could just read the label, and then we'd know how you expect to operate on that. In other words, what we want is not just ordinary data objects. We want to introduce the notion of what's called typed data. Typed data means, again, there's some sort of cloud. And what it's got in it is an ordinary data object like we've been thinking about. Pulled out the contents, sort of the actual data. But also a thing called a type, but it's signed by either George or Martha. So we're going to go from regular data to type data.

How do we build that? Well that's easy. We know how to build clouds. We build them out of pairs. So here's a little representation that supports typed data. There's a thing called take a type and attach it to a piece of contents, and we just use cons. And if we have a piece of typed data, we can look at the type, which is the car. We can look at the contents, which is the cdr. Now along with that, the way we use our type data will test, when we're given a piece of data, what type it is. So we have some type predicates with us.

For example, to see whether a complex number is one of George's, whether it's rectangular, we just check to see if the type of that is the symbol rectangular, right? The symbol rectangular. And to check whether a complex number is one of Martha's, we check to see whether the type is the symbol polar. So that's a way to test what kind of number we're looking at.

Now let's think about how we can use that to build the system. So let's suppose that George and Martha were off working separately, and each of them had designed their complex number representation packages. What do they have to do to become part of the system, to exist compatibly? Well it's really pretty easy. Remember, George had this package. Here's George's original package, or half of it. And underlined in red are the changes he has to make. So before, when George made a complex number out of an x and y, he just put them together to make a pair. And the only difference is that now he signs them. He attaches the type, which is the symbol rectangular to that pair.

Everything else George does is the same, except that-- see, George and Martha both have procedures named real-part and imaginary-part. So to allow them both to exist in the same Lisp environment, George had changed the names of his procedures. So we'll say, this is George's real-part procedure. It's the real-part rectangular procedure, the imaginary-part rectangular procedure. And then here's the rest of George's package. He'd had magnitude and angle, just renames them magnitude rectangular and angle rectangular.

And Martha has to do basically the same thing. Martha previously, when she made a complex number out of a magnitude and angle, she just cons them. Now she attaches the type polar, and she changes the name so her real-part procedure won't conflict in name with George's. It's a real-part-polar, imaginary-part-polar, magnitude polar, and angle polar.

Now we have the system. Right there's George and Martha. And now we've got to get some kind of manager to look at these types. How are these things actually going to work now that George and Martha have supplied us with typed data? Well what we have are a bunch of generic selectors. Generic selectors for complex numbers real-part, imaginary-part, magnitude, and angle. Let's look at them more closely.

What does a real-part do? If I ask for the real part of a complex number, well I look at it. I look at its type. I say, is it rectangular? If so, I apply George's real part procedure to the contents of that complex number. This is a number that has a type on it. I strip off the type using contents and apply George's procedure.

Or is this a polar complex number? If I want the real part, I apply Martha's real part procedure to the contents of that number. So that's how real part works. And then similarly there's imaginary-part, which is almost the same. It looks at the number and if it's rectangular, uses George's imaginary-part procedure. If it's polar, uses Martha's. And then there's a magnitude and an angle.

So there's a system. Has three parts. There's sort of George, and Martha, and the manager. And that's how you get generic operators implemented. Let's look at just a simple example, just to pin it down. But exactly how this is going to work, suppose you're going to be looking at the complex number who's real-part is one, and who's imaginary-part is two. So that would be one plus 2i. What would happen is up here, up here above where the operations have to happen, that number would be represented as a pair of 1 and 2 together with typed data. That would be the contents. And the whole data would be that thing with the symbol rectangular added onto that. And that's the way that complex number would exist in the system.

When you went to take the real-part, the manager would look at this and say, oh it's one of George's. He'll strip off the type and hand down to George the pair 1, 2. And that's the kind of data that George developed his system to use. So it gets stripped down. Later on, if you ask George to construct a complex number, George would construct some complex number as a pair, and before he passes it back up through the manager would attach the type rectangular.

So you see what happens. There's no confusion in this system. It doesn't matter in the least that the pair 1, 2 means something completely different in Martha's world. In Martha's world this pair means the complex number whose magnitude is 1 and whose angle is 2. And there's no confusion, because by the time any pair like this gets handed back through the manager to the main system it's going to have the type polar attached. Whereas this one would have the type rectangular attached.

OK, let's take a break.

[MUSIC-- "JESU, JOY OF MAN'S DESIRING" BY JOHANN SEBASTIAN BACH]

We just looked at a strategy for implementing generic operators. That strategy has a name: it's called dispatch type. And the idea is that you break your system into a bunch of pieces. There's George and Martha, who are making representations, and then there's the manager. Looks at the types on the data and then dispatches them to the right person.

Well what criticisms can we make of that as a system organization? Well first of all there was this little, annoying problem that George and Martha had to change the names of their procedures. George originally had a real-part procedure, and he had to go name it real-part rectangular so it wouldn't interfere with Martha's real-part procedure, which is now named real-part-polar, so it wouldn't interfere with the manager's real-part procedure, who's now named real-part. That's kind of an annoying problem. But I'm not going to talk about that one now. We'll see later on when we think about the structure of Lisp names and environments that there really are ways to package all those so-called name spaces separately so they don't interfere with each other. Not going to think about that problem now.

The problem that I actually want to focus on is what happens when you bring somebody new into the system. What has to happen? Well George and Martha don't care. George is sitting there in his rectangular world, has his procedures and his types. Martha sits in her polar world. She doesn't care.

But let's look at the manager. What's the manager have to do? The manager comes through and had these operations. There was a test for rectangular and a test for polar. If Harry comes in with some new kind of complex number, and Harry has a new type, Harry type complex number, the manager has to go in and change all those procedures. So the inflexibility in the system, the place where work has to happen to accommodate change, is in the manager. That's pretty annoying.

It's even more annoying when you realize the manager's not doing anything. The manager is just being a paper pusher. Let's look again at these programs. What are they doing? What does real-part do? Real-part says, oh, is it the kind of complex number that George can handle? If so, send it off to George. Is it the kind of complex number that Martha can handle? If so, send it off to Martha. So it's really annoying that the bottleneck in this system, the thing that's preventing flexibility and change, is completely in the bureaucracy. It's not in anybody who's doing any of the work. Not an uncommon situation, unfortunately.

See, what's really going on-- abstractly in the system, there's a table. So what's really happening is somewhere there's a table. There're types. There's polar and rectangular. And Harry's may be over here. And there are operators. There's an operator like real-part. Or imaginary-part. Or a magnitude and angle. And sitting in this table are the right procedures. So sitting here for the type polar and real-part is Martha's procedure real-part-polar. And over here in the table is George's procedure real-part-rectangular. And over here would be, say, Martha's procedure magnitude-polar, and George's procedure magnitude-rectangular, right, and so on. The rest of this table's filled in. And that's really what's going on.

So in some sense, all the manager is doing is acting as this table. Well how do we fix our system? How do you fix bureaucracies a lot of the time? What you do is you get rid of the manager. We just take the manager and replace him by a computer. We're going to automate him out of existence. Namely, instead of having the manager who basically consults this table, we'll have our system use the table directly.

What do I mean by that? Let's assume, again using data abstraction, that we have some kind of data structure that's a table. And we have ways of sticking things in and ways of getting things out. And to be explicit, let me assume that there's an operation called "put." And put is going to take, in this case two things I'll call "keys." Key1 and key2. And a value. And that stores the value in the table under key1 and key2. And then we'll assume there's a thing called "get," such that if later on I say, get me what's in the table stored under key1 and key2, it'll retrieve whatever value was stored there. And let's not worry about how tables are implemented. That's yet another data abstraction, George's problem. And maybe we'll see later-- talk about how you might actually build tables in Lisp.

Well given this organization, what did George and Martha have to do? Well when they build their system, they each have the responsibility to set up their appropriate column in the table. So what George does, for example, when he defines his procedures, all he has to do is go off and put into the table under the type-rectangular. And the name of the operation is real-part, his procedure real-part-rectangular.

So notice what's going into this table. The two keys here are symbols, rectangular and real-part. That's the quote. And what's going into the table is the actual procedure that he wrote, real-part rectangular. And then puts an imaginary part into the table, filed under the keys rectangular- and imaginary-part, and magnitude under the keys rectangular magnitude, angle under rectangular-angle. So that's what George has to do to be part of this system.

Martha similarly sets up the column and the table under polar. Polar and real-part. Is the procedure real-part-polar? And imaginary-part, and magnitude, and angle. So this is what Martha has to do to be part of the system. Everyone who makes a representation has the responsibility for setting up a column in the table.

And what does Harry do when Harry comes in with his brilliant idea for implementing complex numbers? Well he makes whatever procedure he wants and builds a new column in this table.

OK, well what happened to the manager? The manager has been automated out of existence and is replaced by a procedure called operate. And this is the key procedure in the whole system. Let's say define operate. Operate is going to take an operation that you want to do, the name of an operation, and an object that you would like to apply that operation to. So for example, the real-part of some particular complex number, what does it do?

Well the first thing it does, it looks in the table. Goes into the table and tries to find a procedure that's stored in the table. So it gets from the table, using as keys the type of the object and the operator, but looks on the table and sees what's stored under the type of the object and the operator, sees if anything's stored. Let's assume that get is implemented. So if nothing is stored there, it'll return the empty list. So it says, if there's actually something stored there, if the procedure here is not no, then it'll take the procedure that it found in the table and apply it to the contents of the object. And otherwise if there was nothing stored there, it'll-- well we can decide. In this case let's have it put out an error message saying, undefined operator. No operator for this type. Or some appropriate error message.

OK? And that replaces the manager. How do we really use it? Well what we say is we'll go off and define our generic selectors using operate. We'll say that the real-part of an object is found by operating on the object with the name of the operation being real-part. And then similarly, imaginary-part is operate using the name imaginary-part and magnitude and angle. That's our implementation. That plus the tape plus the operate procedure. And the table effectively replaces what the manager used to do.

Let's just go through that slowly to show you what's going on. Suppose I have one of Martha's complex numbers. It's got magnitude 1 and angle 2. And it's one of Martha's. So it's labeled here, polar. Let's call that z. Suppose that's z. And suppose with this implementation someone comes up and asks for the real-part of z. Well real-part now is defined in terms of operate. So that's equivalent to saying operate with the name of the operator being real-part, the symbol real-part on z. And now operate comes. It's going to look in the table, and it's going to try and find something stored under-- the operation is going to apply by looking in the table under the type of the object. And the type of z is polar. So it's going to look and say, can I get using polar? And the operation name, which was real-part. It's going to look in there and apply that to the contents of z. And that? If everything was set up correctly, this thing is the procedure that Martha put there. This is real-part-polar. And this is z without its type. The thing that Martha originally designed those procedures to work on, which is 1, 2.

And so operate sort of does uniformly what the manager used to do sort of all over the system. It finds the right thing, looks in the table, strips off the type, and passes it down into the person who handles it.

This is another, and, you can see, more flexible for most purposes, way of implementing generic operators. And it's called data-directed programming. And the idea of that is in some sense the data objects themselves, those little complex numbers that are floating around the system, are carrying with them the information about how you should operate on them.

Let's break for questions. Yes.

AUDIENCE: What do you have stored in that data object? You have the data itself, you have its type, and you have the operations for that type? Or where are the operations that you found?

PROFESSOR: OK, let me-- yeah, that's a good question. Because it raises other possibilities of how you might do it. And of course there are a lot of possibilities. In this particular implementation, what's sitting in this data object, for example, is the data itself-- which in this case is a pair of 1 and 2-- and also a symbol. This is the symbol, the word P-O-L-A-R, and that's what's sitting in this data object.

Where are the operations themselves? The operations are sitting in the table. So in this table, the rows and columns of the table are labeled by symbols. So when I store something in this table, the key might be the symbol polar and the symbol magnitude. And I think by writing it this way I've been very confusing. Because what's really sitting here isn't-- when I wrote magnitude polar, what I mean is the procedure magnitude polar. And probably what I really should have written-- except it's too small for me to write in this little space-- is something like lambda of z, the thing that Martha wrote to implement. And then you can see from that, there's another way that I alluded to of solving this name conflict problem, which is that George and Martha never have to name their procedures at all. They can just stick the anonymous things generated by lambda directly into the table.

There's also another thing that your question raises, is the possibility that maybe what I would like somehow is to store in this data object not the symbol P-O-L-A-R but maybe actually all the operations themselves. And that's another way to organize the system, called message passing. So there are a lot of ways you can do it.

AUDIENCE: Therefore if Martha and George had used the same procedure names, it would be OK because it wouldn't look [UNINTELLIGIBLE].

PROFESSOR: That's right. That's right. See, they wouldn't even have to name their procedures at all. What George could have written instead of saying put in the table under rectangular- and real-part, the procedure real-part rectangular, George could have written put under rectangular real-part, lambda of z, such and such, and such and such. And the system would work completely the same.

AUDIENCE: My question is, Martha could have put key1 key2 real-part, and George could have put key1 key2 real-part, and as long as they defined them differently they wouldn't have had any conflicts, right?

PROFESSOR: Yes, that would all be OK except for the fact that if you imagine George and Martha typing at the same console with the same meanings for all their names, and it would get confused by real-part, but there are ways to arrange that, too. And in principle you're absolutely right. If their names didn't conflict-- it's the objects that go in the table, not the names.

OK, let's take a break.

[MUSIC-- "JESU, JOY OF MAN'S DESIRING" BY JOHANN SEBASTIAN BACH]

All right, well we just looked at data-directed programming as a way of implementing a system that does arithmetic on complex numbers. So I had these operations in it called plus C and minus C, and multiply, and divide, and maybe some others. And that sat on top of-- and this is the key point-- sat on top of two different representations. A rectangular package here, and a polar package. And maybe some more. And we saw that the whole idea is that maybe some more are now very easy to add.

But that doesn't really show the power of this methodology. Shows you what's going on. The power of the methodology only becomes apparent when you start embedding this in some more complex system. What I'm going to do now is embed this in some more complex system. Let's assume that what we really have is a general kind of arithmetic system. So called generic arithmetic system. And at the top level here, somebody can say add two things, or subtract two things, or multiply two things, or divide two things. And underneath that there's an abstraction barrier. And underneath this barrier, is, say, a complex arithmetic package. And you can say, add two complex numbers.

Or you might also have-- remember we did a rational number package-- you might have that sitting there. And there might be a rational thing. And the rational number package, well, has the things we implemented. Plus rat, and times rat, and so on. Or you might have ordinary Lisp numbers. You might say add three and four. So we might have ordinary numbers, in which case we have the Lisp supplied plus, and minus, and times, and slash.

OK, so we might imagine this complex number system sitting in a more complicated generic operator structure at the next level up. Well how can we make that? We already have the idea, we're just going to do it again. We've implemented a rational number package. Let's look at how it has to be changed.

In fact, at this level it doesn't have to be changed at all. This is exactly the code that we wrote last time. To add two rational numbers, remember there was this formula. You make a rational number whose numerator-- the numerator of the first times the denominator of the second, plus the denominator of the first times the numerator of the second. And who's denominator is the product of the denominators. And minus rat, and star rat, and slash rat. And this is exactly the rational number package that we made before. We're ignoring the GCD problem, but let's not worry about that.

As implementers of this rational number package, how do we install it in the generic arithmetic system? Well that's easy. There's only one thing we have to do differently. Whereas previously we said that to make a rational number you built a pair of the numerator and denominator, here we'll not only build the pair, but we'll sign it. We'll attach the type rational. That's the only thing we have to do different, make it a typed data object.

And now we'll stick our operations in the table. We'll put under the symbol rational and the operation add our procedure, plus rat. And, again, note this is a symbol. Right? Quote, unquote, but the actual thing we're putting in the table is the procedure. And for how to subtract, well you subtract rationals with minus rat. And multiply, and divide. And that is exactly and precisely what we have to do to fit inside this generic arithmetic system.

Well how does the whole thing work? See, what we want to do is have some generic operators. Have add and sub and [UNINTELLIGIBLE] be generic operators. So we're going to define add and say, to add x and y, that will be operate-- we were going to call it operate-2. This is our operator procedure, but set up for two arguments using add on x and y. And so this is the analog to operate.

Let's look at the code for second. It's almost like operate. To operate with some operator on an argument 1 and an argument 2, well the first thing we're going to do is check and see if the two arguments have the same type. So we'll say, is the type of the first argument the same as the type of the second argument? And if they're not, we'll go off and complain, and say, that's an error. We don't know how to do that.

If they do have the same type, we'll do exactly what we did before. We'll go look and filed under the type of the argument-- arg 1 and arg 2 have the same type, so it doesn't matter. So we'll look in the table, find the procedure. If there is a procedure there, then we'll apply it to the contents of the argument 1 and the contents of arg 2. And otherwise we'll say, error. Undefined operator. And so there's operate-2. And that's all we have to do.

We just built the complex number package before. How do we embed that complex number package in this generic system? Almost the same. We make a procedure called make-complex that takes whatever George and Martha hand to us and add the type-complex. And then we say, to add complex numbers, plus complex, we use our internal procedure, plus c, and attach a type, make that a complex number.

So our original package had names plus c and minus c that we're using to communicate with George and Martha. And then to communicate with the outside world, we have a thing called plus-complex and minus-complex. And so on. And the only difference is that these return values that are tight. So they can be looked at up here. And these are internal operations.

Let's go look at that slide again. There's one more thing we do. After defining plus-complex, we put under the type complex and the symbol add, that procedure plus complex. And then similarly for subtracting complex numbers, and multiplying them, and dividing them.

OK, how do we install ordinary numbers? Exactly the same way. Come off and say, well we'll make a thing called make-number. Make-number takes a number and attaches a type, which is the symbol number. We build a procedure called plus-number, which is simply, add the two things using the ordinary addition, because in this case we're talking about ordinary numbers, and attach a type to it and make that a number. And then we put into the table under the symbol number and the operation add, this procedure plus-number, and then the same thing for subtracting, and multiplying, and dividing.

Let's look at an example, just to make it clear. Suppose, for instance, I'm going to perform the operation. So I sit up here and I'm going to perform the operation, which looks like multiplying two complex numbers. So I would multiply, say, 3 plus 4i and 2 plus 6i. And that's something that I might want to take hand that to mul. I'll write mul as my generic operator here.

How's that going to work? Well 3 plus 4i, say, sits in the system at this level as something that looks like this. Let's say it was one of George's. So it would have a 3 and a 4. And attached to that would be George's type, which would say rectangular, it came from George. And attached to that-- and this itself would be the data view from the next level up, which it is-- so that itself would be a type-data object which would say complex. So that's what this object would look like up here at the very highest level, where the really super-generic operations are looking at it.

Now what happens, mul eventually's going to come along and say, oh, what's it's type? It's type is complex. Go through to operate-2 and say, oh, what I want to do is apply what's in the table, which is going to be the procedure star complex, on this thing with the type stripped off. So it's going to strip off the type, take that much, and send that down into the complex world.

The complex world looks at its operations and says, oh, I have to apply star c. Star c might say, oh, at some point I want to look at the magnitude of this object that it's in, that it's got. And they'll say, oh, it's rectangular, it's one of George's. So it'll then strip off the next version of type, and hand that down to George to take the magnitude of.

So you see what's going on is that there are these chains of types. And the length of the chain is sort of the number of levels that you're going to be going up in this table. And what a type tells you, every time you have a vertical barrier in this table, where there's some ambiguity about where you should go down to the next level, the type is telling you where to go. And then everybody at the bottom, as they construct data and filter it up, they stick their type back on. So that's the general structure of the system.

OK. Now that we've got this, let's go and make this thing even more complex. Let's talk about adding to the system not only these kinds of numbers, but it's also meaningful to start talking about adding polynomials. Might do arithmetic on polynomials. Like we could have x to the fifteenth plus 2x to the seventh plus 5. That might be some polynomial. And if we have two such gadgets we can add them or multiply them. Let's not worry about dividing them. Just add them, multiply them, then we'll subtract them.

What do we have to do? Well let's think about how we might represent a polynomial. It's going to be some typed data object. So let's say a polynomial to this system might look like a thing that starts with the type polynomial. And then maybe it says the next thing is what variable its in. So I might say I'm a polynomial in the variable x. And then it'll have some information about what the terms are.

And there're just tons of ways to do this, but one way is to say we're going to have a thing called a term-list. And a term-list-- well, in our case we'll use something that looks like this. We'll make it a bunch of pairs which have an order in a coefficient. So this polynomial would be represented by this term-list. And what that means is that this polynomial starts off with a term of order 15 and coefficient 1. And the next thing in it is a term of order 7 and coefficient 2, a term of order 0, which is constant in coefficient 5.

And there are lots and lots of ways, and lots and lots of trade-offs when you really think about making algebraic manipulation packages about exactly how you should represent these things. But this is a fairly standard one. It's useful in a lot of contexts.

OK, well how do we implement our polynomial arithmetic? Let's start out. What we'll do to make a polynomial-- we'll first have a way to make polynomials. We're going to make a polynomial out of variable like x and term-list. And all that does is we'll package them together someway. We'll put the variable together with the term list using cons, and then attached to that the type polynomial.

OK, how do we add two polynomials? To add a polynomial, p1 and p2, and then just for simplicity let's say we will only add things in the same variable. So if they have the same variable, and same variable here is going to be some selector we write, whose details we don't care about. If the two polynomials have the same variable, then we'll do something. If they don't have the same variable, we'll give an error, polynomials not in the same variable.

And if they do have the same variable, what we'll do is we'll make a polynomial whose variable is whatever that variable is, and whose term-list is something we'll call sum-terms. Plus terms will add the two term lists. So we'll add the two term lists to the polynomial. That'll give us a term-list. We'll add on, we'll say it's a polynomial in the variable with that term-list. That's plus poly. And then we're going to put in our table under the type polynomial, add them using plus poly. And of course we really haven't done much. What we've really done is pushed all the work onto this thing, plus-terms, which is supposed to add term-lists.

Let's look at that. Here's an overview of how we might add two term-lists. So L1 and L2 were going to be two term-lists. And a term-list is a bunch of pairs, coefficient in order. And it's a big case analysis. And the first thing we'll check for and see if there are any terms. We're going to recursively work down these term-lists, so eventually we'll get to a place where either L1 or L2 might be empty. And if either one is empty, our answer will be the other one. So if L1 is empty we'll return L2, and if L2 is empty we'll return L1.

Otherwise there are sort of three interesting cases. What we're going to do is grab the first term in each of those lists, called t1 and t2. And we're going to look at three cases, depending on whether the order of t1 is greater than the order of t2, or less than t2, or the same. Those are the three cases we're going to look at.

Let's look at this case. If the order of t1 is greater than the order of t2, then what that means is that our answer is going to start with this term of the order of t1. Because it won't combine with any lower order terms. So what we do is add the lower order terms. We recursively add together all the terms in the rest of the term-list in L1 and L2. That's going to be the lower order terms of the answer. And then we're going to adjoin to that the highest order term.

And I'm using here a whole bunch of procedures I haven't defined, like a adjoin-term, and rest-terms, and selectors that get order. But you can imagine what those are. So if the first term-list has a higher order than the second, we recursively add all the lower terms and then stick on that last term. The other case, the same way. If the first term has a smaller order, well then we add the first term-list and the rest of the terms in the second one, and adjoin on this highest order term.

So so far nothing's much happened, we've just sort of pushed this thing off into adding lower order terms. The last case where you actually get to a coefficients that you have to add, this will be the case where the orders are equal. What we do is, well again recursively add the lower order terms. But now we have to really combine something. What we do is we make a term whose order is the order of the term we're looking at. By now t1 and t2 have the same order. That's its order. And its coefficient is gotten by adding the coefficient of t1 and the coefficient of t2.

This is a big recursive working down of terms, but really there's only one interesting symbol in this procedure, only one interesting idea. The interesting idea is this add. And the reason that's interesting is because something completely wonderful just happened. We reduced adding polynomials, not to sort of plus, but to the generic add. In other words, by implementing it that way, not only do we have our system where we can have rational numbers, or complex numbers, or ordinary numbers, we've just added on polynomials. But the coefficients of the polynomials can be anything that the system can add. So these could be polynomials whose coefficients are rational numbers or complex numbers, which in turn could be either rectangular, or polar, or ordinary numbers.

So what I mean precisely is our system right now automatically can handle things like adding together polynomials that have this one: 2/3 of x squared plus 5/17 x plus 11/4. Or automatically handle polynomials that look like 3 plus 2i times x to the fifth plus 4 plus 7i, or something. You can automatically handle those things. Why is that? That's merely because, or profoundly because we reduced adding polynomials to adding their coefficients. And adding coefficients was done by the generic add operator, which said, I don't care what your types are as long as I know how to add you. So automatically for free we get the ability to handle that.

What's even better than that, because remember one of the things we did is we put into the table that the way you add polynomials is using plus poly. That means that polynomials themselves are things that can be added. So for instance let me write one here. Here's a polynomial. So this gadget here I'm writing up, this is a polynomial in y whose coefficients are polynomials in x. So you see, simply by saying, polynomials are themselves things that can be added, we can go off and say, well not only can we deal with rationals, or complex, or ordinary numbers, but we can deal with polynomials whose coefficients are rationals, or complex, or ordinary numbers, or polynomials whose coefficients are rationals, or complex, rectangular, polar, or ordinary numbers, or polynomials whose coefficients are rationals, complex, or ordinary numbers. And so on, and so on, and so on.

So this is sort of an infinite or maybe a recursive tower of types that we've built up. And it's all exactly from that one little symbol. A-D-D. Writing "add" instead of "plus" in the polynomial thing.

Slightly different way to think about it is that polynomials are a constructor for types. Namely you give it a type, like integer, and it returns for you polynomials in x whose coefficients are integers. And the important thing about that is that the operations on polynomials reduce to the operations on the coefficients. And there are a lot of things like that.

So for example, let's go back and rational numbers. We thought about rational numbers as an integer over an integer, but there's the general notion of a rational object. Like we might think about 3x plus 7 over x squared plus 1. That's general rational object whose numerator and denominator are polynomials. And to add two of them we use the same formula, numerator times denominator plus denominator times numerator over product of denominators.

How could we install that in our system? Well here's our original rational number arithmetic package. And all we have to do in order to make the entire system continue working with general rational objects, is replace these particular pluses and stars by the generic operator. So if we simply change that procedure to this one, here we've changed plus and star to add a mul, those are absolutely the only change, then suddenly our entire system can start talking about objects that look like this.

So for example, here is a rational object whose numerator is a polynomial in x whose coefficients are rational numbers. Or here is a rational object whose numerator is polynomials in x whose coefficients are rational objects constructed out of complex numbers. And then there are a lot of other things like that.

See, whenever you have a thing where the operations reduce to operations on the pieces, another example would be two by two matrices. I have the idea, there might be a matrix here of general things that I don't care about. But if I add two of them, the answer over here is gotten by adding this one and that one, however they like to add. So I can implement that the same way. And if I do that, then again suddenly my system can start handling things like this. So here's a matrix whose elements happen to be-- we'll say this element here is a rational object whose numerator and denominators are polynomials. And all that comes for free.

What's really going on here? What's really going on is getting rid of this manager who's sitting there poking his nose into who everybody's business is. We built a system that has decentralized control. So when you come into and no one's poking around saying, gee, are you in the official list of people who can be added? Rather you say, well go off and add yourself how your parts like to be added. And the result of that is you can get this very, very, very complex hierarchy where a lot of things just get done and rooted to the right place automatically.

Let's stop for questions.

AUDIENCE: You say you get this for free. One thing that strikes me is that now you've lost kind of the cleanness of the break between what's on top and what's underneath. In other words, now you're defining some of the lower-level procedures in terms of things above their own line. Isn't that dangerous? Or, if nothing more, a little less structured?

PROFESSOR: No, I-- the question is whether that's less structured. Depends on what you mean by structure. All this is doing is recursion. See, it's saying that the way you add these guys is to use that. And that's not less structured, it's just a recursive structure. So I don't think it's particularly any less clean.

AUDIENCE: Now when you want to change the multiplier or the add operator, suddenly you've got tremendous consequences underneath that you're not even sure the extent of.

PROFESSOR: That's right, but it depends what you mean. See, this goes both ways. What would be a good example? I ignored greatest common divisor, for instance. I ignored that problem just to keep the example simple. But if I suddenly decided that plus rat here should do a GCD computation and install that, then that immediately becomes available to all of these, to that guy, and that guy, and that guy, and all the way down.

So it depends what you mean by the coherence of your system. It's certainly true that you might want to have a special different one that didn't filter down through the coefficients, but the nice thing about this particular example is that mostly you do.

AUDIENCE: Isn't that the problem, I think, that you're getting to tied in with the fact that the structuring, the recursiveness of that structuring there is actually in execution as opposed to just definition of the actual types themselves?

PROFESSOR: I think I understand the question. The point is that these types evolve and get more and more complex as the thing's actually running. Is that what--

AUDIENCE: Yes. As it's running.

PROFESSOR: --what you're saying? Yes, the point is--

AUDIENCE: As opposed to the basic definitions.

PROFESSOR: Right. The type structure is sort of recursive. It's not that you can make this finite list of the actual things they might look like before the system runs. It's something that evolves. So if you want to specify that system, you have to do in some other way than by this finite list. You have to do it by a recursive structure.

AUDIENCE: Because the basic structure of the types is pretty clean and simple.

PROFESSOR: Right. Yes?

AUDIENCE: I have a question. I understand once you have your data structure set up, how it pulls off complex and passes that down, and then pulls off rect, passes that down. But if you're just a user and you don't know anything about rect or polar or whatever, how do you initially set up that data structure so that everything goes to the right spot? If I just have the equation over there on the left and I just want to add, multiply complex numbers--

PROFESSOR: Well that's the wonderful thing. If you're just a user you say "mul."

AUDIENCE: And it figures out that I mean complex numbers? Or how do I tell it that I want--

PROFESSOR: Well you're going to have in your hands complex numbers. See what you would have at some level, as a real user, is a constructor for complex numbers.

AUDIENCE: So then I have to make complex numbers?

PROFESSOR: So you have to make them. What you would probably have as a user is some little thing in the reader loop, which would give you some plausible way to type in a complex number, in whatever format you like. Or it might be that you're never typing them in. Someone's just handing you a complex number.

AUDIENCE: OK, so if I had a complex number that had a polynomial in it, I'd have to make my polynomial and then make my complex number.

PROFESSOR: Right if you wanted it constructed from scratch. At some point you construct them from scratch. But what you don't have to know of that is when you have the object you can just say "mul." And it'll multiply. Yeah?

AUDIENCE: I think the question that was being posed here is, say if I want to change my presentation of complexes, or some operation of complex, how much real code I will have to gets around with, or change to change it in one specific operation?

PROFESSOR: [UNINTELLIGIBLE] what you have to change. And the point is that you only have to change what you're changing. See if Martha decides that she would rather-- let's see something silly-- like change the order in the pair. Like angle and magnitude in the other order, she just makes that change locally. And the whole thing will propagate through the system in the right way. Or if suddenly you said, gee, I have another representation for rationals. And I'm going to stick it here, by filing those operations in the table. Then suddenly all of these polynomials whose coefficients are coefficients of coefficients, or whatever, also can automatically have available that representation. That's the power of this particular one.

AUDIENCE: I'm not sure if I can even pose an intelligent sounding question. But somehow this whole thing went really nicely to this beautiful finish where all the things seemed to fall into place. Sort of seemed a little contrived. That's all for the sake, I'm sure, of teaching. I doubt that the guys who first did this-- and I could be wrong-- figured it all out so that when they just all put it all together, you could all of the sudden, blam, do any kind of arithmetic on any kind of object. It seems like maybe they had to play with it for a while and had to bash it and rework it.

And it seems like that's the kind of problem we're really faced with we start trying to design a really complex system, is having lots of different kinds of parts and not even knowing what kinds of operations we're going to want to do on those parts. How to organize the operations in this nice way so that no matter what you do, when you start putting them together everything starts falling out for free.

PROFESSOR: OK, well that's certainly a very intelligent question. One part is this is a very good methodology that people have discovered a lot coming from symbolic algebra. Because there are a lot of complications. To allow you to implement these things before you decide what you want all the operations to be, and all of that. So in some sense it's an answer that people have discovered by wading through this stuff. In another sense, it is a very contrived example.

AUDIENCE: It seems like to be able to do this you do have to wade through it for a certain amount of time before you can become good at it.

PROFESSOR: Let me show you how terribly contrived this is. So you can write all these wonderful things. But the system that I wrote here, and if we had another half an hour to give this lecture I would have given this part of it, which says, notice that it breaks down if I tell it to do something as foolish as add 3 plus 7/2. Because what will happen is you'll get to operate-2, and operate-2 will say, oh this is type number, and that's type rational. I don't know how to add them.

So you'd like the system at least to be able to say something like, gee, before you do that change that to 3/1. Turn it into a rational number, hand that to the rational package. That's the thing I didn't talk about in this lecture. It's a little bit in the book, which talks about the problem of what's called coercion. Where you wanted-- see, having so carefully set up all of these types as distinct objects, a lot of times you want to also put in knowledge about how to view an ordinary number as a kind of rational. Or view an ordinary number as a kind of complex. That's where the complexity in the system really starts happening, where you talk about, see where do I put that knowledge? Is it rational to know that ordinary numbers might be pieces of [UNINTELLIGIBLE] of them?

Or they're terrible, terrible examples, like if I might want to add a complex number to a rational number. Bad example. 5/7. Then somebody's got to know that I have to convert these to another type, which is complex numbers whose parts might be rationals. And who worries about that? Does complex worry about that? Does rational worry about that? Does plus worry about that?

That's where the real complexity comes in. And that's where it's pretty well sorted out. And a lot of, in fact, all of this message passing stuff was motivated by problems like this. And when you really push it, people are-- somehow the algebraic manipulation problem seems to be so complex that the people who are always at the edge of it are exactly in the state you said. They're wading through this thing, mucking around, seeing what they use, trying to distill stuff.

AUDIENCE: I just want to come back to this issue of complexity once more. It certainly seems to be true that you have a great deal of flexibility in altering the lower level kinds of things. But it is true that you are, in a sense, freezing higher level operations. Or at least if you change them you don't know where all of the changes are going to show up, or how they are.

PROFESSOR: OK, that's an extremely good question. What I have to do is, if I decide there's a new general operation called equality test, then all of these people have to decide whether or not they would like to have an equality test by looking in the table. There're ways to decentralize it even more. That's what I sort of hinted at last time, where I said you could not only have this type as a symbol, but you actually might store in each object the operations that it knows of that.

So you might have things like greatest common divisor, which is a thing here which is defined only for integers, and not in general for rational numbers. So it might be a very, very fragmented system. And then depending on where you want your flexibility, there's a whole spectrum of places that you can build that in. But you're pointing at the place where this starts being weak, that there has to be some agreement on top here about these general operations. Or at least people have to think about them. Or you might decide, you might have a table that's very sparse, that only has a few things in it. But there are lot of ways to play that game. OK, thank you.

[MUSIC: "JESU, JOY OF MAN'S DESIRING" BY JOHANN SEBASTIAN BACH]