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

make LP return the number of variables #13148

Closed
dimpase opened this issue Jun 21, 2012 · 20 comments
Closed

make LP return the number of variables #13148

dimpase opened this issue Jun 21, 2012 · 20 comments

Comments

@dimpase
Copy link
Member

dimpase commented Jun 21, 2012

Currently there is no way to know how many variables an LP actually has, without parsing its constraints. However, this information is readily available from the backend. Hence the patch attached.


Apply attachment: trac_13148-number_of_variables_in_LP.patch to devel/sage

CC: @nathanncohen @ppurka

Component: linear programming

Author: Dima Pasechnik

Reviewer: Nathann Cohen

Merged: sage-5.2.beta0

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

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 22, 2012

comment:2

-_-

Ahem... With Gurobi installed the doctests do not pass, because of their stupid way of storing double inequalities :

sage: p = MixedIntegerLinearProgram()
sage: p.add_constraint(p[0] - p[2], min = 1, max = 4)
sage: p.number_of_variables()
3
sage: p.show()
Maximization:
 
Constraints:
  R0: 4.0 <= x_0 - x_1 + RgR0 <= 4.0
Variables:
  x_0 is a continuous variable (min=0.0, max=+oo)
  x_1 is a continuous variable (min=0.0, max=+oo)
  RgR0 is a continuous variable (min=0.0, max=3.0)

Of course I expect that your code works with any other solver ^^;

Could you change the first constraint so that it is a "simple" inequality (with not both an upper and lower bound) ?

Your patch also needs some commit message. And I do not know if there is any rule about patches filenames ending with a .patch, but we will find out soon :-)

Sorry about this Gurobi ugliness :-p

Nathann

@dimpase
Copy link
Member Author

dimpase commented Jun 22, 2012

comment:3

Replying to @nathanncohen:

-_-

Ahem... With Gurobi installed the doctests do not pass, because of their stupid way of storing double inequalities :

sage: p = MixedIntegerLinearProgram()
sage: p.add_constraint(p[0] - p[2], min = 1, max = 4)
sage: p.number_of_variables()
3
sage: p.show()
Maximization:
 
Constraints:
  R0: 4.0 <= x_0 - x_1 + RgR0 <= 4.0
Variables:
  x_0 is a continuous variable (min=0.0, max=+oo)
  x_1 is a continuous variable (min=0.0, max=+oo)
  RgR0 is a continuous variable (min=0.0, max=3.0)

as far as I am concerned this is an LP with 3 variables, not 2.
So my code is right :–)
(well, you don't have means to control that RgR0, so what?)
When you construct the usual dual of such an LP, you'll end up with
a different dual.

Of course I expect that your code works with any other solver ^^;

Could you change the first constraint so that it is a "simple" inequality (with not both an upper and lower bound) ?

hmm, I don't see what you mean here.

Your patch also needs some commit message. And I do not know if there is any rule about patches filenames ending with a .patch, but we will find out soon :-)

Sorry about this Gurobi ugliness :-p

Nathann

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 22, 2012

comment:4

as far as I am concerned this is an LP with 3 variables, not 2.
So my code is right :–)

Yeah, but itbreaks doctests.

(well, you don't have means to control that RgR0, so what?)

None at all. When you add a as a constraint a linar function + two bounds (min and max) Gurobi automatically creates a newbounded variable and makes the constraint an equality.
That's stupid, boring, whatever you want, but this is still how it behaves.

When you construct the usual dual of such an LP, you'll end up with
a different dual.

Yeah. That's why I told you by email that you would be surpised by the behviour of some solvers on his respect.

hmm, I don't see what you mean here.

If you remove either the min or the max bound from your code Gurobi will not do that and break the doctest, that's all...

Nathann

@dimpase
Copy link
Member Author

dimpase commented Jun 22, 2012

comment:5

Replying to @nathanncohen:

as far as I am concerned this is an LP with 3 variables, not 2.
So my code is right :–)

Yeah, but itbreaks doctests.

it only does so if you hack your Sage installation to make Gurobi the default
solver. Correct me if I'm wrong, but isn't the default LP solver GLPK?

(well, you don't have means to control that RgR0, so what?)

None at all. When you add a as a constraint a linar function + two bounds (min and max) Gurobi automatically creates a newbounded variable and makes the constraint an equality.
That's stupid, boring, whatever you want, but this is still how it behaves.

Ah, I see, thanks.

When you construct the usual dual of such an LP, you'll end up with
a different dual.

Yeah. That's why I told you by email that you would be surpised by the behviour of some solvers on his respect.

Well, I constructed LPs that CPLEX can solve by primal simplex, but not by the dual. LPs that CPLEX finds out to be infeasible, but for which it fails to give you an infeasibility certificate. I don't think they can surprise me any more :-)

Dima

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 22, 2012

comment:6

it only does so if you hack your Sage installation to make Gurobi the default
solver. Correct me if I'm wrong, but isn't the default LP solver GLPK?

Well. No, Gurobi becomes the default solver as soon as you install it.

But that is not the problem Dima. I you remove this "min" or "max" in your file the doctest does not break anymore, what's the point of insisting to keep it ? What's the point ?

Well, I constructed LPs that CPLEX can solve by primal simplex, but not by the dual. LPs that CPLEX finds out to be infeasible, but for which it fails to give you an infeasibility certificate. I don't think they can surprise me any more :-)

Ahahaah... Scary, scary things ....

Nathann

@dimpase
Copy link
Member Author

dimpase commented Jun 22, 2012

comment:7

Replying to @nathanncohen:

it only does so if you hack your Sage installation to make Gurobi the default
solver. Correct me if I'm wrong, but isn't the default LP solver GLPK?

Well. No, Gurobi becomes the default solver as soon as you install it.

Oh dear... And if I install, say, CPLEX? Will it take over? This is strange. Even web browsers don't behave like this :–) Anyway...

But that is not the problem Dima. I you remove this "min" or "max" in your file the doctest does not break anymore, what's the point of insisting to keep it ? What's the point ?

Cause this would not be what I'd call 100% doctest coverage. :–)
If someone else (or me, 6 months later :–)) would stumble upon this crap?

OK, I can specify the solver to use, then it will work.
By the way, how would I mark a test so that it would only be invoked if GUROBI is installed?
Is it # optional ??? ? And what would be ??? there?

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 22, 2012

comment:8

Well. No, Gurobi becomes the default solver as soon as you install it.

Oh dear... And if I install, say, CPLEX? Will it take over? This is strange. Even web browsers don't behave like this :–) Anyway...

It would. You will find out how it behaves by looking at numerical/backends/generic_backend, bottom of the file.
This is made so that the best solver available will be used to solve.... graph problems :-P

Cause this would not be what I'd call 100% doctest coverage :–)
OK, I can specify the solver to use, then it will work.

And you woul prefer to specify manually the solver you want to use, in this case GLPK, and say that the other solvers will not be tested ? This would be 100% coverage ? Or add one doctest per solver ?

By the way, how would I mark a test so that it would only be invoked if GUROBI is installed?
Is it # optional ??? ? And what would be ??? there?

It would be # optional - gurobi
There are many instances of that in numerical/gurobi_backend

Nathann

@dimpase
Copy link
Member Author

dimpase commented Jun 22, 2012

comment:9

Replying to @nathanncohen:

Well. No, Gurobi becomes the default solver as soon as you install it.

Oh dear... And if I install, say, CPLEX? Will it take over? This is strange. Even web browsers don't behave like this :–) Anyway...

It would. You will find out how it behaves by looking at numerical/backends/generic_backend, bottom of the file.
This is made so that the best solver available will be used to solve.... graph problems :-P

Cause this would not be what I'd call 100% doctest coverage :–)
OK, I can specify the solver to use, then it will work.

And you woul prefer to specify manually the solver you want to use, in this case GLPK, and say that the other solvers will not be tested ? This would be 100% coverage ? Or add one doctest per solver ?

One way or another, this weirdness must be exposed in doctests and/or in docs. And I'll add this in docs.

I presume there is a function to find the default solver...

By the way, how would I mark a test so that it would only be invoked if GUROBI is installed?
Is it # optional ??? ? And what would be ??? there?

It would be # optional - gurobi
There are many instances of that in numerical/gurobi_backend

Nathann

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 22, 2012

comment:10

One way or another, this weirdness must be exposed in doctests and/or in docs. And I'll add this in docs.

I presume there is a function to find the default solver...

Probbly there... Actually I' surprised I did not write it already.

http://www.sagemath.org/doc/thematic_tutorials/linear_programming.html

Or else we can change that... What would you think of forgetting about this behavour, and deciding that the default solver is GLPK unless some line in ~/.sage/init.sage says otherwise ?

I would find this behaviour much more sensible now :-)

Nathan

@dimpase
Copy link
Member Author

dimpase commented Jun 23, 2012

comment:11

Replying to @nathanncohen:

One way or another, this weirdness must be exposed in doctests and/or in docs. And I'll add this in docs.

I presume there is a function to find the default solver...

Probbly there... Actually I' surprised I did not write it already.

http://www.sagemath.org/doc/thematic_tutorials/linear_programming.html

Or else we can change that... What would you think of forgetting about this behavour, and deciding that the default solver is GLPK unless some line in ~/.sage/init.sage says otherwise ?

I would find this behaviour much more sensible now :-)

hopefully the new patch addresses all the things discussed. :–)

Nathan

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 23, 2012

comment:13

Well, then... :-)

Sorry for this ugliness Dima ! Perhaps this class will change totally over time :-)

Nathann

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 23, 2012

Author: Dima Pasechnik

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 23, 2012

Reviewer: Nathann Cohen

@ppurka
Copy link
Member

ppurka commented Jun 23, 2012

comment:14

Hello, I think there should be just two minor changes

  1. in the documentation, the latex equations should probably be enclosed under backticks like `m <= c^T x <= M`, so that the superscripts are rendered properly in the notebook.
  2. the patch should contain the ticket number in its name (I suppose in the name is preferred now?) or in its commit message.

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 23, 2012

comment:15

Hello, I think there should be just two minor changes

  1. in the documentation, the latex equations should probably be enclosed under backticks like `m <= c^T x <= M`, so that the superscripts are rendered properly in the notebook.

Ahahahaha. Right, right, and for that I blame the rose wine of southern France (God, this place is sunny !!)

  1. the patch should contain the ticket number in its name (I suppose in the name is preferred now?) or in its commit message.

Hmmmm... On the other hand I believe that the ticket numbers are now added automatically and that Jeroen prefers when there are none in the patch's message.

HAve fuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuun !

Nathann

@ppurka
Copy link
Member

ppurka commented Jun 23, 2012

Attachment: trac_13148-number_of_variables_in_LP.patch.gz

a patch to have .number_of_variables() return what it should (just minor changes)

@ppurka

This comment has been minimized.

@ppurka
Copy link
Member

ppurka commented Jun 23, 2012

comment:16

Ok. I made the changes and removed some trailing whitespaces which should make patchbot happy.

@nathanncohen
Copy link
Mannequin

nathanncohen mannequin commented Jun 23, 2012

comment:17

Great :-)

Nathann

@jdemeyer
Copy link

jdemeyer commented Jul 2, 2012

Merged: sage-5.2.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

3 participants