PuLP support for MILP (binary/integer variables) is not obviously visible

[pierre-haessig]

Dear PuLP devs,

I just wanted to recommend a PuLP-based tool for a colleague (the energy optimization framework https://omegalpes-examples.readthedocs.io/en/latest/index.html), but, as used PuLP quite some time ago, I wanted to check first that PuLP supports binary/integer constraints (because that's a need for this colleague).

Now, I guess it depends on implicitly on the definition of "linear problems", but reading just the headlines in the README, it was not obvious to me that PuLP does support MILP, since it's advertised as a LP modeler. It's only when I dug through the doc of LpVariable that I was reassured.

My suggestion (and I can open a PR if you wish) is to clarify the support of MILP with the following changes in the README:

• in the first line "PuLP is an LP modeler written in Python." → "PuLP is an (MI)LP modeler written in Python" or something similar
• in the code illustrations below, perhaps document the optional parameter cat=Binary for LpVariable.

By the way, I see in the example https://coin-or.github.io/pulp/CaseStudies/a_set_partitioning_problem.html that the syntax for integer is cat=pulp.LpInteger. However, the doc for the LpVariable class mentions only strings (Binary, Integer, Continuous) as possible values, not the existence of package level constants like pulp.LpInteger.

[vladimirvalenta]

I second that. The prefix LP that is used abundantly in PuLP implementation is a confusing one. For example

var, prob = LpProblem.fromMPS(modelName)
prob.solve(..)

reads and solves MIP problems.

[pierre-haessig]

I second that. The prefix LP that is used abundantly in PuLP implementation is a confusing one. For example

Correct. However when speaking of the API, making changes has more implications: need to first introduce the new class names, and only then deprecate the old names... Much more work that updating the README!