-
Notifications
You must be signed in to change notification settings - Fork 323
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Define linear programs #7386
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: Yaël Dillies <yael.dillies@gmail.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
Co-authored-by: Eric Wieser <wieser.eric@gmail.com>
structure LinearProgram (K : Type*) {V : Type*} (P : Type*) | ||
[LinearOrderedField K] [AddCommGroup V] [Module K V] [AddTorsor V P] where | ||
/-- Inequality constraints (given in the form "aᵀx - b ≥ 0") -/ | ||
constraints : List (P →ᵃ[K] K) | ||
/-- The objective function (affine map) -/ | ||
objective : P →ᵃ[K] K |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't particularly like the design, with constraints and objective bundled together. The feasibility of constraints makes no mention of the objective, and the design should allow talking about this without an objective. Please separate these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you be more happy with the following definitions?
def LinearProgramFeas (R : Type*) {V : Type*} (P : Type*)
[LinearOrderedRing R] [AddCommGroup V] [Module R V] [AddTorsor V P] :=
List (P →ᵃ[R] R)
structure LinearProgramOpt (R : Type*) {V : Type*} (P : Type*)
[LinearOrderedRing R] [AddCommGroup V] [Module R V] [AddTorsor V P] where
constraints : LinearProgramFeas R P
objective : P →ᵃ[R] R
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not two structures, one extending the other?
Presumably for the "just the constraints" version, you then want definitions satisfiable_at
and satisfiable
, with lots of lemmas about how these interact with list operations (e.g. adding/erasing etc constraints).
structure LinearProgram (K : Type*) {V : Type*} (P : Type*) | ||
[LinearOrderedField K] [AddCommGroup V] [Module K V] [AddTorsor V P] where | ||
/-- Inequality constraints (given in the form "aᵀx - b ≥ 0") -/ | ||
constraints : List (P →ᵃ[K] K) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am skeptical about making this a List
rather than a Set
. One is not actually going to do computation with this type: any meaningful algorithm will require a much more complicated data structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I remember Martin expressing some objections to situations with infinitely-many constraints, as those tend not to appear in linear programming. That would rule out Set
, and prohibiting duplicates or permutations isn't particularly interesting since the constraints can still be redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to hear Martin's take on this, or for someone to click "resolve" as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If finiteness is really the thing of interest though, you could argue that what we actually want is the type of convex sets built from finitely many half planes; either non-constructively via an existential, or constructively via a Finset and a proof that removing any one element increases the size of the feasible set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you induct on Finsets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. Just one comment (not contradicting to your suggestion); all point on the sphere would be vertices.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About the second part of your comment, redundant constraints are often a thing that we have to deal with (because they come from the ambient problem in the LP). So we probably shouldn't have the proof obligation that says "removing a constraint strictly increases the feasible set"
I don't think this claim necessarily holds merit; finsets are not allowed to hold duplicates, and have a proof obligation to this end; but that doesn't stop you from writing {1, 1, 2, 2}
. You only have to deal with the proof obligation if you call Finset.mk
directly.
Arguably this "Finset of non-redundant affine constraints" object deserves it's own ConvexPolytope
object.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though another reasonable approach might be to discard the proof obligation and work with the quotient of the type by equality of feasible spaces
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A redundant LP need not have identical constraints. It just needs to be a linear combination of other constraints. I am not sure I see the value in doing, let's say Gaussian elimination on constraints, to extract independent ones makes sense every time an LP is defined. In computer science and also possibly OR, redundant constraints are a fact of life that have to be dealt with algorithmically, and so one often constructs what Mathlib devs might call API lemmas to deal with these cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I think about it, having infinitely many conditions is less weird than having infinitely many variables. Given that Mathlib maintainers want the variable space to be general, we should also make the condition space general. Defining conditions as a list (or a multiset, or a finite set) of any type will be bad for LP duality, unless we change the type of P
along with it.
Alternative: #9693 |
Another alternative: #10026 |
Linear programs over a general
Module
with constraints given in the form "aᵀx - b ≥ 0" and the objective function as anAffineMap
to be minimized.Zulip discussion:
https://leanprover.zulipchat.com/#narrow/stream/144837-PR-reviews/topic/.237386.20Linear.20Programming
Four PRs incompatible with each other:
#7386 (list of constraints)
#9693 (matrix form)
#10026 (Antoine Chambert-Loir's def; semirings, linear)
#10159 (Antoine Chambert-Loir's def; rings, affine)