Somehow compact formulation takes some practice, so that may give you one more example. This is for our product mix problem. Our product mix problem, let's generalize it instead of just looking at the task in the tables. Let's say we have n products to be produced and that they need to consume m different types of resources. So n and m can be any number. If you are running a semiconductor fab then n may be a thousands and m may be also thousands. We are going to use j and i to be the indexes for products and resources respectively. It's a very good habit to maintain the use of indexes throughout your whole program. We're going to require ourselves in the case that when we say j, everybody knows it's product. When we say i, everybody knows it's resources throughout in the whole formulation. From time to time, these may not be so easy, but if you try to enforce yourself to do that, in many cases you will get satisfied formulation. We need some parameters. Unit sales price of product j is going to be P_j. The resource supply limit is R_i, and then the unit of resource i required for producing one unit of product j, that is denoted as A_ij and so on. You may see that whenever we are talking about resources, that's i, whenever we are talking about products, that's j. Then once we have that, we're going to define X_j as the production quality for product j, j from 1 to n, and then we are able to write down our compact formulation. Because here there is a parameter that takes two indexes. Well, you may need to spend a few minutes to work on it to really understand what we mean. Then maybe you need to take a look at the simple formulation with tasks in the tables. But anyway, let's understand this. I want to maximize the total revenue I have, so depending on my production quantity and the sales quantity, depending on the price, I may collect the sales revenue for all the n products, that's my objective function. For each constraint, the limit is there. I only have R_i units as my resource i. Then this particular thing is the amount of resource I need. For resource i, according to the product I want to produce, for product 1, X_j. I'm going to consume A_i1 times x_1. For x_2, as my production quality for product 2, the total consumption is A_i2 times x_2, and then so on and so on. The collection here, the summation here is the total amount of resource i I use. Of course, cannot be greater than the total amount I need. Finally, everything should be non-negative. Interestingly, sometimes we may use an even more compact formulation. We may define set for the set of products, set of resources, or in general index sets. Why do we call them index sets? Because the set contains indexes. Here, the index is for products, that is, the index is for resources. Once we do that, here, you don't need to write down j from 1 to n, you only need to write down for all J that's in the set, capital J. That's collect, P_j, x_j. For each resource i in the set i, I need to do this calculation again by considering all possible products, something like that. The two formulations in the previous page, they are obviously identical or equivalent. But you may choose the one that you feel more comfortable with. For me, I always write in this way because it saves me some spaces, it save me some time. The last page is some concept that we will use throughout whatever you call it, a course, a semester, whatever. It's the difference between problems and instances. This is something to know in general, not just for linear programming. But now this is a right time to introduce this. A problem is a collection of instances, it's an abstract description of a task or a question. Whenever we are expressing things with symbols, we are defining a problem or a class of instances. An instance, on the other hand, is a concrete realization or concrete specification of a problem. When we plug in concrete values into those symbols, we are obtaining an instance. These examples are here, a compact formulation looking this way. Everything are in symbols. Then once we plug in values, that becomes an instance. If you are running a factory today, you solve a problem. After you have some new products, you solve a new instance. Because in the abstract setting, you're still talking about the same problem, it's just that the numbers, the values, the parameters changes. You have more products, it's just n becomes larger. If the cost becomes different, you are still solving the same problem, it's just that the instance becomes another one. If you have two factories doing pretty much the same thing, you are solving the same problem, is just that you're dealing with different instances. One reason to write formulations is because once you have a formulation for one problem, it helps you to deal with all different kinds of instances. Instances may change from day to day, from time to time, from location to location, but it's quite possible that their problems is actually the same one. Eventually, you will learn it that whenever some people are trying to invent algorithms to solve, for example, linear programs to solve problems, pretty much they are dealing with problems. Once we have a model, that's a problem, and then once we are able to solve a problem, we are able to solve all those instances. This is the first time I talk about this idea, but in later lectures, we will see these from time to time. This is actually very important. Once you know it, you really get deeper understanding about the whole thing about operations research.
