Skip to content
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

a polyhedron() method for Linear Programs #14238

Closed
nathanncohen mannequin opened this issue Mar 6, 2013 · 9 comments
Closed

a polyhedron() method for Linear Programs #14238

nathanncohen mannequin opened this issue Mar 6, 2013 · 9 comments

Comments

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Mar 6, 2013

As the title says, this patch implements a .polyhedron() method which returns the Polyhedron object defined by the LP.

And some doc, while we are at it.

Nathann

CC: @dimpase @dcoudert @nthiery @vbraun

Component: linear programming

Author: Nathann Cohen

Reviewer: Dmitrii Pasechnik

Merged: sage-5.9.beta0

Issue created by migration from https://trac.sagemath.org/ticket/14238

@nathanncohen nathanncohen mannequin added this to the sage-5.9 milestone Mar 6, 2013
@nathanncohen nathanncohen mannequin self-assigned this Mar 6, 2013
@nathanncohen nathanncohen mannequin added the s: needs review label Mar 6, 2013
@dimpase
Copy link
Member

dimpase commented Mar 6, 2013

comment:2

I can think of two not always equal things this returns

  • the original polyhedron described by the input
  • the way it is represented by the backend invoked.

Please clarify in the docs. Also, please add tests for unbounded and empty cases...

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Mar 6, 2013

comment:3
  • the original polyhedron described by the input
  • the way it is represented by the backend invoked.

I don't see what you have in mind. The LP variables are internally numbered from 0 to n-1, that is also the case with the variables of a Polyhedron. With this, there is only ony way to define the constraints, isn't it ?

Nathann

@dimpase
Copy link
Member

dimpase commented Mar 6, 2013

comment:4

Replying to @nathanncohen:

  • the original polyhedron described by the input
  • the way it is represented by the backend invoked.

I don't see what you have in mind. The LP variables are internally numbered from 0 to n-1, that is also the case with the variables of a Polyhedron. With this, there is only ony way to define the constraints, isn't it ?

actually, you yourself pointed out to me, a while ago, a case where a backend (GUROBI?) does some nontrivial rewriting of a constraint, if I recall right, of the form a<=x_i<=b, resulting in adding a new variable, or something like this.

Dima

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Mar 6, 2013

comment:5

actually, you yourself pointed out to me, a while ago, a case where a backend (GUROBI?) does some nontrivial rewriting of a constraint, if I recall right, of the form a<=x_i<=b, resulting in adding a new variable, or something like this.

Arggggggggg... Right. I had totally forgotten about that. I will add a warning. I hate these hacks :-/

Nathann

@nathanncohen
Copy link
Mannequin Author

nathanncohen mannequin commented Mar 7, 2013

comment:6

Done ! Thanks for noticing that !

Nathann

@jdemeyer
Copy link

jdemeyer commented Mar 8, 2013

comment:8

The patch needs a proper commit message.

@jdemeyer
Copy link

jdemeyer commented Mar 8, 2013

Reviewer: Dmitrii Pasechnik

@jdemeyer
Copy link

comment:9

Attachment: trac_14238.patch.gz

@jdemeyer
Copy link

Merged: sage-5.9.beta0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants