Notes on using lpsolve

To solve an LP with lpsolve, you need to provide lpsolve with an input file that specifies what the LP is. You should use a text editor to create simple input files (we will also write code to create the index files). You should have a text editor you use often and trust. There are many free ones available. I've been using Atom lately, but for years I used TextWrangler, the free version of BBEdit.
Regarding lpsolve input file syntax

It is useful to remember that lpsolve is not a programming language. It is an LP solver, so all it can do is solve LPs that you give it. There is no facility for loops, conditional statements, trig functions, etc., in an lpsolve input file as would be available with a programming language. This is one reason why we will usually create code that creates our input files.
The input file needs to consist of an objective function followed by constraints. Here is an example:
```
    min: x1+x2+x3+x4;
    4*x1+3*x2-2*x3-x4>=2;
    x1+x2+6*x3+2*x4<=22;
    assign1: x3=x1+x2+1;
    int x1, x2, x3;
```
The first line must state the objective function and whether or not you wish to maximize or minimize it. The first line must begin with "min:" or "max:" and then be followed by the objective function and then a semicolon.

The constraints can be either <= or <= constraints. You can also included assignments, i.e., equality statements (like the x3=x1+x2+1 line above, which is labeled with "assign1:").

Constraint and assignment lines can be labelled, as the x3=x1+x2+1 line is. You should always label assignment lines. Unlabeled assignment lines can result in lpsolve ignoring your assignment. Labeling can make it easier to trace lpsolve results and troubleshoot. The labels can be essentially any string you want, followed by a colon (:) but it's probably best to stick to letters and numbers.

We can add variables, too, to help us keep track of results. The LP above could be written:
```
    min: x1+x2+x3+x4;
    polar=4*x1+3*x2-2*x3-x4;
    polar>=2;
    grizzly=x1+x2+6*x3+2*x4;
    grizzly<=22;
    assign1: x3=x1+x2+1;
    int x1, x2, x3;
    
```
Here I have introduced variables, polar and grizzly, to keep track of some of the quantities in the LP. When lpsolve solves this LP, it will report the values of polar and grizzly, and from this it will be easy to see whether or not the polar constraint and the grizzly constraint are binding.

The last line specifies that x1, x2, and x3 are integer. In addition to int, we can also use bin to specify that variables are binary, i.e., they take on only the values 0 and 1. For example, instead of the int line above, the line
```
bin x1, x2, x3;
```
If there is no specification for a variable, lpsolve will treat the variable as real (floating-point). So in this example x4 would be a real variable (i.e., it might take on non-integer values).

You can mix the variable types: some can be real, some integer, some binary, by using multiple lines of this type.
You will often want to make use of doubly-indexed variables. When doing this, be sure to include a separator between the indices. For example, if we want to use variables x_i,j with i and j running from 1 to 30, these should be denoted in your lpsolve input file as x_1_1,x_1_2,...x_30_30. Notice that if you run the indices together, and write, for example x_122 instead of x_12_2, then you will not be able to distinguish your variable from x_1_22 which would also be written x_122. This is likely to result in your calculation results being nonsense.

Presenting lpsolve input files In your work, you will often want to include your lpsolve input file. Sometimes, though, it will be quite long (well over 100 lines). Rather than include the whole thing, please just give one sample constraint of each type, with a note that there are a certain number of constraints of that type omitted. At the same time, please comment to say what the purpose of those constraints are. Also, long lines should be truncated: give the first and last parts with ... in between. For example, your lpsolve input file might be presented like this:

min: +c_1+c_2+c_3+c_4+...+c_9+c_10+c_11+c_12;
(11 lines of the following type:
ensure that lower numbered colors are used before higher numbered colors)
c_2<=c_1;
.
.
c_12<=c_11;
(12 lines of the following type:
ensure that every vertex is colored with exactly one color)
+x_1_1+x_1_2+x_1_3+...+x_1_10+x_1_11+x_1_12=1;
.
.
(142 lines of the following type:
ensure that the c variables keep track of colors that are used)
x_1_1<= c_1;
.
.
(251 lines of the following type:
ensure vertices connected by edges are different colors)
x_1_1+x_2_1 <=1;
.
.
(ensure all variables are binary)
bin x_1_1,...,x_12_12,c_1,...,c_12;

lpsolve Output The solution to an LP is not the value of the objective function, but that values of the variables that achieve the optimal value. When reporting a solution, these values must be reported.
Often, many of the variables in a solution will be zero, so leave those out in your writeups, and add the comment "All other variables are zero." after you give the values of the non-zero variables, like this:
```
    Value of objective function: 410.00000000

    Actual values of the variables:
    x2                              1
    x4                              1
    x5                              1
    x6                              1
    x8                              1
    x9                              1

All other variables are zero.
  
```
This is much easier to read than a possibly very long list that the reader (and you!) would have to hunt through to find the ones.

We can have lpsolve print only the non-zero variables. To do this using the command line, use the -ia flag:
```
  lp_solve -ia inputFile.lp
```
This will print intermediate solutions as well, so if the computation takes a long time, you can watch its progress.

If you are using the Windows IDE, on the menu line "Source-Matrix-Options-Result" click on Options. Then, next to Print Sol, select Automatic. This will cause lpsolve to leave out zero variables when it prints the solution to the console.
The order of the constraints in your lpsolve input file do not matter from a mathematical point of view: the set of constraints all together is the LP. However, the order can affect the speed of computation in lpsolve, since from a practical point of view some things must be done before other things are done. It is not easy to guess ahead of time what order the constraints should be in to maximize the speed, so if your solutions are taking a long time, experiment with the order to see if it helps. I have a hunch that it is often best to have the "most restrictive" constraints early in the input file, but it's a complicated business.