Opened 6 years ago

Closed 6 years ago

#14238 closed enhancement (fixed)

a polyhedron() method for Linear Programs

Reported by: ncohen Owned by: ncohen
Priority: major Milestone: sage-5.9
Component: linear programming Keywords:
Cc: dimpase, dcoudert, nthiery, vbraun Merged in: sage-5.9.beta0
Authors: Nathann Cohen Reviewers: Dmitrii Pasechnik
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

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

Attachments (1)

trac_14238.patch (11.3 KB) - added by ncohen 6 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 6 years ago by ncohen

  • Status changed from new to needs_review

comment:2 follow-up: Changed 6 years ago by dimpase

  • Status changed from needs_review to needs_work

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...

comment:3 in reply to: ↑ 2 ; follow-up: Changed 6 years ago by ncohen

  • 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

comment:4 in reply to: ↑ 3 ; follow-up: Changed 6 years ago by dimpase

Replying to ncohen:

  • 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

comment:5 in reply to: ↑ 4 Changed 6 years ago by ncohen

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

comment:6 Changed 6 years ago by ncohen

  • Status changed from needs_work to needs_review

Done ! Thanks for noticing that !

Nathann

comment:7 Changed 6 years ago by dimpase

  • Status changed from needs_review to positive_review

comment:8 Changed 6 years ago by jdemeyer

  • Reviewers set to Dmitrii Pasechnik

The patch needs a proper commit message.

Changed 6 years ago by ncohen

comment:9 Changed 6 years ago by jdemeyer

  • Merged in set to sage-5.9.beta0
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.