That's pretty much the end of the day. We have went through many different things. We talked about the simplex method, during the process, we talked about center form, basic feasible solution, how to do the pivoting, how to use Tableau to organize everything, and how to deal with unbounded and infeasible linear programs. That's the principle parts. We also talked about the implementation part. We used Gurobi to solve a linear program. That I don't think is too hard. But there's one thing that I need to remind you again. The thing is that we used this way to write our programs. We mentioned about model data decoupling. Because this is really important and some beginners will fail to understand it's importance, so I need to talk about it again. Here when we do this writing, we separate the variable parts or the data parts with the model part. You may see that here, we first have a place to declare to prepare all the data. Here, 700, 900, 3, 5, 1, 2. These values are prepared and are stored at the beginning and then used, for example here, for example, here. You may see that we first prepare our numbers and then put them into models. In particular, if you focus on the model part, you may see that near is no number at all. Here, all the numbers are taken from the previous declared list. That's the right way to do it. You really need to decompose your model part and data part to make your program flexible. To give you an idea about why this is important, take a look at the original version. The original version is here. This is a coupling of model in the data. We know that our model is an abstract thing. It should be something times x1 plus something times x2 as our objective function to be maximized. You also know that there are several resource allocation constraints. When we write it in this way, in this coupling way, the numbers and the abstract models, they are combined together. In the future, if you want to modify the model, you need to be aware of these numbers. If you want to change to a new set of data, change to a new instance, you really need to worry about the models. If the two things are coupled, future modifications, and future adjustment would be very difficult. We hope that every time when you want to use a solver to solve your problem, you really need to separate your model parts and your data part. For data here I'm going to write it as instance because one model can be used to solve many different instances. You may have instance 1, you may have instance 2, and so on and so on. Once you input different instance into a single model, you expect to see different solutions. A model is always there. You should not change your model too often, but instances changes every day. Today may be your situation is like this, your product price is 700, but maybe in the future is going to become 750 or it may go down. You really want that, you don't need to modify your model. But you may take a look at the new situation, the new parameter set, and see what to do in that new situation. If that's the case, if you have decoupled your model with your data, you only need to modify the data part a little bit. You just need to look at the data part and modify the numbers and then you may do it again. If you do things in this way, and if you have a lot of variables changes, if you have many parameters changes, then you really need to find the right way to do the modifications. That will be two times tedious and that's what's going to create some problems about writing the right program. This implementation issue may not be very important if you look at the theory of operations research. But we don't want to just focus on theory, we also want to really apply these methods, these algorithms, this theory to practice. When you want to apply these things to a practice, you need to write computer programs. If you don't have good habits to write good computer programs, you will fail at the end. Hopefully this reminder, make sense to you. Make sure that always decouple your model part with your data part. Make your data separate with different instances so that they can be used mostly in practice. That's all I want to say for today. Thank you and see you next time.
