-
-
Notifications
You must be signed in to change notification settings - Fork 491
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
Comments
comment:2
-_- Ahem... With Gurobi installed the doctests do not pass, because of their stupid way of storing double inequalities :
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 Nathann |
comment:3
Replying to @nathanncohen:
as far as I am concerned this is an LP with 3 variables, not 2.
hmm, I don't see what you mean here.
|
comment:4
Yeah, but itbreaks doctests.
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.
Yeah. That's why I told you by email that you would be surpised by the behviour of some solvers on his respect.
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 |
comment:5
Replying to @nathanncohen:
it only does so if you hack your Sage installation to make Gurobi the default
Ah, I see, thanks.
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 |
comment:6
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 ?
Ahahaah... Scary, scary things .... Nathann |
comment:7
Replying to @nathanncohen:
Oh dear... And if I install, say, CPLEX? Will it take over? This is strange. Even web browsers don't behave like this :–) Anyway...
Cause this would not be what I'd call 100% doctest coverage. :–) OK, I can specify the solver to use, then it will work. |
comment:8
It would. You will find out how it behaves by looking at numerical/backends/generic_backend, bottom of the file.
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 ?
It would be # optional - gurobi Nathann |
comment:9
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...
|
comment:10
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 |
comment:11
Replying to @nathanncohen:
hopefully the new patch addresses all the things discussed. :–)
|
comment:13
Well, then... Sorry for this ugliness Dima ! Perhaps this class will change totally over time Nathann |
Author: Dima Pasechnik |
Reviewer: Nathann Cohen |
comment:14
Hello, I think there should be just two minor changes
|
comment:15
Ahahahaha. Right, right, and for that I blame the rose wine of southern France (God, this place is sunny !!)
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 |
Attachment: trac_13148-number_of_variables_in_LP.patch.gz a patch to have .number_of_variables() return what it should (just minor changes) |
This comment has been minimized.
This comment has been minimized.
comment:16
Ok. I made the changes and removed some trailing whitespaces which should make patchbot happy. |
comment:17
Great Nathann |
Merged: sage-5.2.beta0 |
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
The text was updated successfully, but these errors were encountered: