Sage: Ticket #12823: Allow constants for objective function & deletion of rows in MixedIntegerLinearProgram
https://trac.sagemath.org/ticket/12823
<p>
Currently, <a class="missing wiki">MixedIntegerLinearProgram?</a> does not allow deleting rows. We would like to enable this for all backends that allow it.
</p>
<p>
Also, this is a bug.
</p>
<pre class="wiki">sage: lp = MixedIntegerLinearProgram()
sage: x, y = lp[0], lp[1]
sage: lp.add_constraint(2*x + 3*y <= 6)
sage: lp.add_constraint(3*x + 2*y <= 6)
sage: lp.set_objective(x + y + 7)
sage: lp.set_integer(x); lp.set_integer(y)
sage: lp.solve()
2.0
</pre><p>
The correct value ought to be <strong>9</strong>, not <strong>2</strong>. The problem is this line in the <code>set_objective()</code> method of <code>mip.pyx</code>:
</p>
<pre class="wiki"> f.pop(1,0)
</pre><p>
John Perry will create a patch for GLPK and CBC; Nathann Cohen will create a patch for Gurobi and CPLEX.
</p>
<p>
<strong>Apply</strong>:
</p>
<ul><li><a class="attachment" href="https://trac.sagemath.org/attachment/ticket/12823/trac_12823_rolls_all_into_one.patch" title="Attachment 'trac_12823_rolls_all_into_one.patch' in Ticket #12823">trac_12823_rolls_all_into_one.patch</a><a class="tracrawlink" href="https://trac.sagemath.org/rawattachment/ticket/12823/trac_12823_rolls_all_into_one.patch" title="Download"></a>
</li></ul>enusSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/12823
Trac 1.1.6john_perryMon, 09 Apr 2012 23:18:23 GMT
https://trac.sagemath.org/ticket/12823#comment:1
https://trac.sagemath.org/ticket/12823#comment:1
<p>
I've uploaded a patch for Coin & GLPK. Do we want to take care of deleting constraints in this patch, too? I haven't done that yet; if so, I'll modify the ticket correspondingly.
</p>
Ticketjohn_perryMon, 09 Apr 2012 23:22:48 GMTtype changed; author set
https://trac.sagemath.org/ticket/12823#comment:2
https://trac.sagemath.org/ticket/12823#comment:2
<ul>
<li><strong>type</strong>
changed from <em>PLEASE CHANGE</em> to <em>defect</em>
</li>
<li><strong>author</strong>
set to <em>john_perry, ncohen</em>
</li>
</ul>
<p>
I knew I'd forgotten something in the ticket properties: its type. Sorry. :(
</p>
Ticketjohn_perryWed, 11 Apr 2012 20:35:13 GMTstatus, description, summary changed
https://trac.sagemath.org/ticket/12823#comment:3
https://trac.sagemath.org/ticket/12823#comment:3
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_info</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12823?action=diff&version=3">diff</a>)
</li>
<li><strong>summary</strong>
changed from <em>Allow constants for objective function in MixedIntegerLinearProgram</em> to <em>Allow constants for objective function & deletion of rows in MixedIntegerLinearProgram</em>
</li>
</ul>
<p>
I'm about to upload a new patch that takes into account our offline discussion <strong>and</strong> enables deletion of rows. The doctests and some warning blocks are only in the backends, though; should those be moved to <code>mip.pyx</code>? I'm not real clear on that.
</p>
Ticketjohn_perryWed, 11 Apr 2012 20:36:47 GMT
https://trac.sagemath.org/ticket/12823#comment:4
https://trac.sagemath.org/ticket/12823#comment:4
<p>
I also corrected the output of <code>show()</code>.
</p>
TicketncohenWed, 11 Apr 2012 20:39:50 GMT
https://trac.sagemath.org/ticket/12823#comment:5
https://trac.sagemath.org/ticket/12823#comment:5
<p>
Hellooooooooooo John !!
</p>
<p>
Well, there is no need to test functions 10 times in the same way, so the best is to write real hard tests in the backends, and some tests just meant as examples for the users in the documentation of numerical/mip.pyx. The point is that GLPK is the only solver whose documentation appears in Sage's online reference manual, so we can not easily write important documentation in the backends of CBC, Cplex and Gurobi for the user has almost no way to see it.
</p>
<p>
Nathann
</p>
Ticketjohn_perryWed, 11 Apr 2012 23:59:22 GMT
https://trac.sagemath.org/ticket/12823#comment:6
https://trac.sagemath.org/ticket/12823#comment:6
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:5" title="Comment 5">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Well, there is no need to test functions 10 times in the same way, so the best is to write real hard tests in the backends, and some tests just meant as examples for the users in the documentation of numerical/mip.pyx.
</p>
</blockquote>
<p>
Okay. I added a relatively simplex doctest for <code>mip.pyx</code> that illustrates removing constraints in a way that works for both GLPK and Coin. Its warning clause should hopefully alert the reader to look up the details for the solver they are using. While I was at it, I also fixed more output problems in <code>show()</code>.
</p>
<p>
I guess it's time for you to referee this one, and to submit a patch for the other solvers. <code>:)</code>
</p>
Ticketjohn_perryWed, 11 Apr 2012 23:59:42 GMTattachment set
https://trac.sagemath.org/ticket/12823
https://trac.sagemath.org/ticket/12823
<ul>
<li><strong>attachment</strong>
set to <em>trac_12823_const_for_obj_funs.patch</em>
</li>
</ul>
Ticketjohn_perryThu, 12 Apr 2012 00:01:13 GMTdescription changed
https://trac.sagemath.org/ticket/12823#comment:7
https://trac.sagemath.org/ticket/12823#comment:7
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/12823?action=diff&version=7">diff</a>)
</li>
</ul>
TicketncohenThu, 12 Apr 2012 13:57:20 GMTstatus, description changed; dependencies set
https://trac.sagemath.org/ticket/12823#comment:8
https://trac.sagemath.org/ticket/12823#comment:8
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>dependencies</strong>
set to <em>12833</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12823?action=diff&version=8">diff</a>)
</li>
</ul>
<p>
Hellooooooooo !!!
</p>
<p>
Simple. Your meant Simple. Not Simplex <code>:D</code>
I'm making the same kind of mistake something with crazy words from graph theory or Sage... Crazy <code>:D</code>
</p>
<p>
Well... This patch took me... quite some time ! It all began with <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a>, which this patch depends upon. Some problems with Gurobi's interface. Which I noticed because my gurobi license was not valid anymore. Once I got this license again (and reinstalled Gurobi), I had a problem when installing cbc with <code></code>sage i cbc<code></code>, for the first package Sage installed was the old one. Harald Schilly fixed that.
And... Ok, now this patch !
It does not do much actually, just adds the required methods in cplex and Gurobi.
</p>
<p>
Some important things I should mention. Please tell me what you think of them :
</p>
<ul><li>I renamed self.obj_value to self.obj_constant_term, as I would have expected self.obj_value to store the optimal value reached by the objective function.
</li><li>Sage should *never* crash, whatever happens in the code. So as usual ((&*@#)*&@%&* indexes in GLPK) I added a +1 to the indices in GLPK, so that the constraints are numbered from 0 regardless of the solver. I also added tests in GLPK and Coin to ensure no crash happens. CPLEX and Gurobi never crash because of that, as they have a smarter management of exceptions (error codes).
</li><li>I also changed some doctests for which solutions were not unique. Actually I just removed the lines printing the value of variables, which were not fundamental, and let the others stay as they really tested the new methods.
</li><li>I believe I also added some #optional flags in Coin's file, though everything is mixed up in my head after editing 4 files in a row <code>:D</code>
</li></ul><p>
Anyway, everything is tested, and....
</p>
<pre class="wiki">~/sage/numerical/backends$ sage t optional coin_backend.pyx glpk_backend.pyx gurobi_backend.pyx cplex_backend.pyx
sage t optional "devel/sage2/sage/numerical/backends/coin_backend.pyx"
[1.3 s]
sage t optional "devel/sage2/sage/numerical/backends/cplex_backend.pyx"
[1.3 s]
sage t optional "devel/sage2/sage/numerical/backends/glpk_backend.pyx"
[1.3 s]
sage t optional "devel/sage2/sage/numerical/backends/gurobi_backend.pyx"
[1.4 s]

All tests passed!
Total time for all tests: 5.3 seconds
~/sage/numerical/backends$
</pre><p>
(And I rarely have all solvers installed at the same time)
</p>
<p>
Soo... Well, if you agree with my patch (I can send you my cplex/gurobi license if necessary), .... <code>:)</code>
</p>
<p>
Thank you very much for your work on that one ! It's good to see this class move a bit <code>:)</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryThu, 12 Apr 2012 14:06:22 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:9
https://trac.sagemath.org/ticket/12823#comment:9
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
I'm okay with offsetting the constraint according to the solver. However, line 401 of coin_backend should have
</p>
<pre class="wiki">if i < 0 or i >= self.si.getNumRows():
</pre><p>
instead of
</p>
<pre class="wiki">if i < 0 or i > self.si.getNumRows():
</pre><p>
shouldn't it?
</p>
TicketncohenThu, 12 Apr 2012 14:15:20 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:10
https://trac.sagemath.org/ticket/12823#comment:10
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<p>
Ahahaah. Totally right. Updated <code>:)</code>
</p>
<p>
I had also totally forgotten to do the same for GLPK <code>O_o</code>
That's what you get when you code through copy/paste in several patches <code>:P</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryThu, 12 Apr 2012 14:28:24 GMT
https://trac.sagemath.org/ticket/12823#comment:11
https://trac.sagemath.org/ticket/12823#comment:11
<p>
Why do you enumerate the constraints in coin_backend, maybe others? Why not simply loop i from 0 to len(constraints)?
</p>
<p>
More: I don't understand this:
</p>
<pre class="wiki">for i,c in enumerate(constraints):
if i < 0 or i >= nrows:
sage_free(rows)
raise ValueError("The constraint's index i must satisfy 0 <= i < number_of_constraints")
rows[i] = constraints[i]
</pre><p>
Seems to me the test should be
</p>
<pre class="wiki"> if c < 0 or c >= nrows:
</pre><p>
shouldn't it? and then you could have
</p>
<pre class="wiki"> rows[i] = c # same as constraints[i]
</pre>
TicketncohenThu, 12 Apr 2012 14:41:34 GMT
https://trac.sagemath.org/ticket/12823#comment:12
https://trac.sagemath.org/ticket/12823#comment:12
<blockquote class="citation">
<p>
Why do you enumerate the constraints in coin_backend, maybe others? Why not simply loop i from 0 to len(constraints)?
</p>
</blockquote>
<p>
Oh. Because I have been told that "enumerate" had been "optimised", and that as "for i in range(n)" it was translated into "good C code". Actually, here is what it gives :
</p>
<pre class="wiki"> __pyx_t_4 = 0;
__pyx_t_1 = ((PyObject *)__pyx_v_coeff); __Pyx_INCREF(__pyx_t_1); __pyx_t_5 = 0;
for (;;) {
if (__pyx_t_5 >= PyList_GET_SIZE(__pyx_t_1)) break;
__pyx_t_2 = PyList_GET_ITEM(__pyx_t_1, __pyx_t_5); __Pyx_INCREF(__pyx_t_2); __pyx_t_5++;
__Pyx_XDECREF(__pyx_v_v);
__pyx_v_v = __pyx_t_2;
__pyx_t_2 = 0;
__pyx_v_i = __pyx_t_4;
__pyx_t_4 = (__pyx_t_4 + 1);
</pre><p>
So it is more or less the same... In particular, when you have a "for i in range(len(something))" I guess the "len(something)" is evaluated many times.
</p>
<pre class="wiki"> __pyx_t_4 = PyObject_Length(__pyx_v_constraints); if (unlikely(__pyx_t_4 == 1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 450; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
for (__pyx_t_5 = 0; __pyx_t_5 < __pyx_t_4; __pyx_t_5+=1) {
__pyx_v_i = __pyx_t_5;
</pre><p>
Oh. No, it is not. Ok well.. It looks like it is indeed better as an range(len(thing)) <code>:D</code>
And anyway it makes more sense this way... Of course there is no way to ensure that "len(thing)" does not change between the loops, but the meaning of "range(len(thing))" is clear, even if "thing" changed later on in the loop.
</p>
<p>
Updated !
</p>
<blockquote class="citation">
<p>
Seems to me the test should be
</p>
<pre class="wiki"> if c < 0 or c >= nrows:
</pre><p>
shouldn't it?
</p>
</blockquote>
<p>
Yeah totally.... Stupid me.
</p>
<p>
Nathann
</p>
TicketdavidloefflerThu, 12 Apr 2012 16:34:38 GMTstatus changed; work_issues set
https://trac.sagemath.org/ticket/12823#comment:13
https://trac.sagemath.org/ticket/12823#comment:13
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_work</em>
</li>
<li><strong>work_issues</strong>
set to <em>failing doctests</em>
</li>
</ul>
<p>
Patchbot's not happy:
</p>
<pre class="wiki">**********************************************************************
File "/storage/masiao/sage5.0.beta13patchbot/devel/sage12823/sage/numerical/mip.pyx", line 1101:
sage: p.number_of_constraints()
Expected:
3
Got:
2
**********************************************************************
File "/storage/masiao/sage5.0.beta13patchbot/devel/sage12823/sage/numerical/mip.pyx", line 1131:
sage: p.remove_constraint([0, 1])
Exception raised:
Traceback (most recent call last):
File "/storage/masiao/sage5.0.beta13patchbot/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/storage/masiao/sage5.0.beta13patchbot/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/storage/masiao/sage5.0.beta13patchbot/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_17[8]>", line 1, in <module>
p.remove_constraint([Integer(0), Integer(1)])###line 1131:
sage: p.remove_constraint([0, 1])
File "mip.pyx", line 1070, in sage.numerical.mip.MixedIntegerLinearProgram.remove_constraint (sage/numerical/mip.c:6538)
def remove_constraint(self, int i):
TypeError: an integer is required
**********************************************************************
File "/storage/masiao/sage5.0.beta13patchbot/devel/sage12823/sage/numerical/mip.pyx", line 1132:
sage: p.show()
Expected:
Maximization:
<BLANKLINE>
Constraints:
x_0 <= 4.0
...
Got:
Maximization:
<BLANKLINE>
Constraints:
x_0 + x_1 <= 10.0
x_0  x_1 <= 0.0
x_0 <= 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)
**********************************************************************
2 items had failures:
1 of 12 in __main__.example_16
2 of 12 in __main__.example_17
***Test Failed*** 3 failures.
For whitespace errors, see the file /home/masiao/.sage/tmp/fermat6426/mip_26729.py
[2.5 s]
</pre>
Ticketjohn_perryThu, 12 Apr 2012 16:48:58 GMT
https://trac.sagemath.org/ticket/12823#comment:14
https://trac.sagemath.org/ticket/12823#comment:14
<p>
Apparently Nathann ran a doctest on everything <strong>except</strong> <code>mip.pyx</code>... LOL
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:13" title="Comment 13">davidloeffler</a>:
</p>
<blockquote class="citation">
<p>
Patchbot's not happy:
</p>
<pre class="wiki">**********************************************************************
File "/storage/masiao/sage5.0.beta13patchbot/devel/sage12823/sage/numerical/mip.pyx", line 1101:
sage: p.number_of_constraints()
Expected:
3
Got:
2
</pre></blockquote>
<p>
Yes, <code>3</code> in the doctest should change to <code>2</code>.
</p>
<blockquote class="citation">
<pre class="wiki">**********************************************************************
File "/storage/masiao/sage5.0.beta13patchbot/devel/sage12823/sage/numerical/mip.pyx", line 1131:
sage: p.remove_constraint([0, 1])
Exception raised:
...
File "/storage/masiao/sage5.0.beta13patchbot/devel/sage12823/sage/numerical/mip.pyx", line 1132:
sage: p.show()
Expected:
Maximization:
<BLANKLINE>
Constraints:
x_0 <= 4.0
...
Got:
Maximization:
<BLANKLINE>
Constraints:
x_0 + x_1 <= 10.0
x_0  x_1 <= 0.0
x_0 <= 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)
</pre></blockquote>
<p>
These are both because line 1127, which used to have
</p>
<pre class="wiki">sage: p.remove_constraints([2])
</pre><p>
was changed to
</p>
<pre class="wiki">sage: p.remove_constraint([0,1])
</pre><p>
Note the missing <strong>s</strong>. Fixing that should fix these tests. I'll leave it to Nathann, since these come from his patch.
</p>
TicketncohenThu, 12 Apr 2012 18:14:47 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:15
https://trac.sagemath.org/ticket/12823#comment:15
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>needs_review</em>
</li>
</ul>
<blockquote class="citation">
<p>
Apparently Nathann ran a doctest on everything <strong>except</strong> <code>mip.pyx</code>... LOL
</p>
</blockquote>
<p>
Ahahaha right <code>:)</code>
</p>
<p>
I always assume that the backends' specific files are harder to test, and that the graph/ files are the one that should be test to ensure all returned results are correct <code>:)</code>
</p>
<p>
Patch updated !
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 02:35:23 GMT
https://trac.sagemath.org/ticket/12823#comment:16
https://trac.sagemath.org/ticket/12823#comment:16
<p>
I've examined the code for the patch. Only one question: in the Gurobi backend, for <code>remove_constraints</code>, why do you loop and call <code>remove_constraint</code> on each index? The signature for <code>GRBdelconstrs()</code> seems to allow sending an index, just like GLPK and Coin. I'm not looking at the documentation for it, though, so maybe that's okay.
</p>
<p>
It's pretty clear that CPLEX is different, so I understand the loop there.
</p>
<p>
Anyway, I'd like to test the patch ASAP, and give it a positive review, but  I don't have either CPLEX or Gurobi installed. I understand those aren't free like Coin and GLPK. How should I test the doctests? Must I download them, or can I take you at your word that you've doctested them and the doctests check out?
</p>
TicketncohenFri, 13 Apr 2012 08:15:31 GMT
https://trac.sagemath.org/ticket/12823#comment:17
https://trac.sagemath.org/ticket/12823#comment:17
<p>
Helloooooooo !!!
</p>
<p>
To be honest I wondered whether we should really have two functions to remove constraints. It sounds nice to have such a highlevel function to remove many constraints at once in mip.pyx, this one calling the remove_constraint methods in the backends, but to have a remove_constraintS in each backend we once more have to duplicate a LOT of code (like add_linear_constraintS, add_variableS) that may as well be implemented once and for all in generic_backend.
</p>
<p>
Then again it is because we are working on pretty different LP. What do you think ?
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 13:36:27 GMT
https://trac.sagemath.org/ticket/12823#comment:18
https://trac.sagemath.org/ticket/12823#comment:18
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:17" title="Comment 17">ncohen</a>:
</p>
<blockquote class="citation">
<p>
To be honest I wondered whether we should really have two functions to remove constraints.
</p>
</blockquote>
<p>
That's true. I guess we should just have the one function, <code>remove_constraints()</code>, that accepts an iterable. Sort of like we have <code>get_values()</code> rather than <code>get_value()</code>. and so forth.
</p>
<p>
If you're okay with that, I'll revise my ticket.
</p>
TicketncohenFri, 13 Apr 2012 13:42:39 GMT
https://trac.sagemath.org/ticket/12823#comment:19
https://trac.sagemath.org/ticket/12823#comment:19
<p>
Yooooooo John !
</p>
<p>
Well, I would prefer much more to have only remove_constraint than remove_constraintS. Otherwise we will be calling remove_constraints([1]) which looks a bit odd. But what about what I just said earlier : remove the S functions from the backends, and write generic ones directly in generic_backend ? The code would be sparser, the features still there !?
</p>
<p>
And this get_values thing is more or less a mistake, because for me "all" variables are indexed dictionaries <code>:)</code>
</p>
<p>
Nathann
</p>
TicketncohenFri, 13 Apr 2012 13:46:35 GMT
https://trac.sagemath.org/ticket/12823#comment:20
https://trac.sagemath.org/ticket/12823#comment:20
<p>
Alternatively we can also have remove_constraint functions that can also take iterators as argument.. It's true that we are dealing with Python here, we can write very weird code <code>:D</code>
</p>
<p>
But that would perhaps be better for the mip.pyx interface... If we want the Cython interface to stay somehow efficient.
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 13:58:47 GMT
https://trac.sagemath.org/ticket/12823#comment:21
https://trac.sagemath.org/ticket/12823#comment:21
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:19" title="Comment 19">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Well, I would prefer much more to have only remove_constraint than remove_constraintS. Otherwise we will be calling remove_constraints([1]) which looks a bit odd.
</p>
</blockquote>
<p>
Amusingly enough, I think <code>remove_constraint([1,2,3])</code> looks far more odd than <code>remove_constraints([1])</code>.
</p>
<blockquote class="citation">
<p>
But what about what I just said earlier : remove the S functions from the backends, and write generic ones directly in generic_backend ? The code would be sparser, the features still there !?
</p>
</blockquote>
<p>
I'm not quite following what you're saying. Can you be more specific?
</p>
<blockquote class="citation">
<p>
And this get_values thing is more or less a mistake, because for me "all" variables are indexed dictionaries <code>:)</code>
</p>
</blockquote>
<p>
I don't understand why that makes it a mistake.
</p>
TicketncohenFri, 13 Apr 2012 14:05:36 GMT
https://trac.sagemath.org/ticket/12823#comment:22
https://trac.sagemath.org/ticket/12823#comment:22
<blockquote class="citation">
<blockquote class="citation">
<p>
Well, I would prefer much more to have only remove_constraint than remove_constraintS. Otherwise we will be calling remove_constraints([1]) which looks a bit odd.
</p>
</blockquote>
<p>
Amusingly enough, I think <code>remove_constraint([1,2,3])</code> looks far more odd than <code>remove_constraints([1])</code>.
</p>
</blockquote>
<p>
Ahahahah. What about remove_constraint(1) when you just have one constraint to remove ? <code>:D</code>
</p>
<blockquote class="citation">
<p>
I'm not quite following what you're saying. Can you be more specific?
</p>
</blockquote>
<p>
Of course ! What I do not like with the current implementation is that many functions (plus their documentation) are very long and essentially do the work done by the previous function several times. Like addvariable(s), add_linear_constraint(s), and now remove_constraint(s).
It would be easy to have both at the same time at no cost. We could define for each backend the function without the s, exactly as it is, and define in generic_backend the function with a S, which would just repeatedly call the previous function. This way, all the backends would inherit this abstract function, so it would be available in the backends, but we would be able to remove all the duplicated code from the specific backends.
</p>
<p>
Does that sound like a bad idea to you ?
</p>
<blockquote class="citation">
<p>
I don't understand why that makes it a mistake.
</p>
</blockquote>
<p>
Because it was done like a mistake. It was done without properly thinking about how it would be used by other people. Even if it is not so bad after all, it was still done out of careless work <code>:)</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 14:26:11 GMT
https://trac.sagemath.org/ticket/12823#comment:23
https://trac.sagemath.org/ticket/12823#comment:23
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:22" title="Comment 22">ncohen</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Amusingly enough, I think <code>remove_constraint([1,2,3])</code> looks far more odd than <code>remove_constraints([1])</code>.
</p>
</blockquote>
<p>
Ahahahah. What about remove_constraint(1) when you just have one constraint to remove ? <code>:D</code>
</p>
</blockquote>
<p>
That looks perfectly fine. Did you mean <code>remove_constraints(1)</code>? That does look odd, but not very much so.
</p>
<blockquote class="citation">
<p>
What I do not like with the current implementation is that many functions (plus their documentation) are very long and essentially do the work done by the previous function several times. Like addvariable(s), add_linear_constraint(s), and now remove_constraint(s).
</p>
</blockquote>
<p>
Okay.
</p>
<blockquote class="citation">
<p>
It would be easy to have both at the same time at no cost. We could define for each backend the function without the s, exactly as it is, and define in generic_backend the function with a S, which would just repeatedly call the previous function.
</p>
</blockquote>
<p>
Well, in cases where the backend provides a way to add or remove multiple rows at once (<code>glpk</code> for instance), we ought to do that instead, rather than remove one at a time.
</p>
<blockquote class="citation">
<p>
This way, all the backends would inherit this abstract function, so it would be available in the backends, but we would be able to remove all the duplicated code from the specific backends.
</p>
<p>
Does that sound like a bad idea to you ?
</p>
</blockquote>
<p>
No, that sounds like what ought to be done.
</p>
<p>
Let me make sure I understand what you're saying: when code that we have duplicated in <code>mip.pyx</code> can be moved to <code>generic_backend.pyx</code>, we should do that. Prime candidates for this are <code>add_variable(s)</code>, <code>add_linear_constraint(s)</code>, and <code>remove_constraint(s)</code>. We would not actually remove the functions (yet) though we would deprecate them.
</p>
<p>
If I understand you correctly, here's my counterproposal: let's finish this ticket first, then open another that does that, targeted for sage 5.x where x>0. Otherwise, this gets a little complicated
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I don't understand why that makes it a mistake.
</p>
</blockquote>
<p>
Because it was done like a mistake. It was done without properly thinking about how it would be used by other people. Even if it is not so bad after all, it was still done out of careless work <code>:)</code>
</p>
</blockquote>
<p>
All you've said is that it's a mistake, only using different words! I still don't understand why it's wrong.
</p>
TicketncohenFri, 13 Apr 2012 14:36:58 GMT
https://trac.sagemath.org/ticket/12823#comment:24
https://trac.sagemath.org/ticket/12823#comment:24
<p>
Hellooooooo !!!
</p>
<blockquote class="citation">
<p>
That looks perfectly fine. Did you mean <code>remove_constraints(1)</code>? That does look odd, but not very much so.
</p>
</blockquote>
<p>
Yep, that's what I meant. That is precisely how get_values currently works <code>^^;</code>
</p>
<blockquote class="citation">
<p>
Well, in cases where the backend provides a way to add or remove multiple rows at once (<code>glpk</code> for instance), we ought to do that instead, rather than remove one at a time.
</p>
</blockquote>
<p>
Hmmm, but we can not do that without writing backendspecific code....
</p>
<blockquote class="citation">
<p>
No, that sounds like what ought to be done.
</p>
<p>
Let me make sure I understand what you're saying: when code that we have duplicated in <code>mip.pyx</code> can be moved to <code>generic_backend.pyx</code>, we should do that. Prime candidates for this are <code>add_variable(s)</code>, <code>add_linear_constraint(s)</code>, and <code>remove_constraint(s)</code>. We would not actually remove the functions (yet) though we would deprecate them.
</p>
</blockquote>
<p>
Arggg !! NOononono, I meant duplicated code in the backend files ! That is where we have 2 functions doing the same stuff, rewritten in 4 different files ! <code>:P</code>
</p>
<blockquote class="citation">
<p>
If I understand you correctly, here's my counterproposal: let's finish this ticket first, then open another that does that, targeted for sage 5.x where x>0. Otherwise, this gets a little complicated
</p>
</blockquote>
<p>
That is agreed. So do we merge this one ? Oh, the Gurobi/CPLEX thing, that's right..
</p>
<p>
Well, that is up to you. I tested them maaaaaaaaany times, but I can also ask David Coudert to check that tests pass, as he has them installed (well, CPLEX for sure and I do not know about Gurobi). But you really should try CPLEX once, it is soooooooooo much faster for integer problems ! <code>:)</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 15:23:17 GMT
https://trac.sagemath.org/ticket/12823#comment:25
https://trac.sagemath.org/ticket/12823#comment:25
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:24" title="Comment 24">ncohen</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Well, in cases where the backend provides a way to add or remove multiple rows at once (<code>glpk</code> for instance), we ought to do that instead, rather than remove one at a time.
</p>
</blockquote>
<p>
Hmmm, but we can not do that without writing backendspecific code....
</p>
<p>
...Arggg !! NOononono, I meant duplicated code in the backend files ! That is where we have 2 functions doing the same stuff, rewritten in 4 different files ! <code>:P</code>
</p>
</blockquote>
<p>
Okay, I understand now, and I think it makes better sense, too. <code>;)</code> Duplicated code is one thing, like with the Gurobi, CPLEX, and Coin files. I don't think that's a problem, nor is it incompatible with using the one call in glpk, as I suggest. But I do think we should allow a backend to redefine <code>remove_constraint()</code> to take advantage of its own efficiency. In particular, glpk should be able to remove several constraints w/one function call, because it makes it possible. That doesn't duplicate code.
</p>
<p>
If you're okay with that, I think this is something that I could take care of today in generic_backend, glpk_backend, and coin_backed; then you could take care of the others.
</p>
<p>
If you're not okay with that, then, yeah, it would be best to work this out in a different ticket.
</p>
<blockquote class="citation">
<p>
I tested them maaaaaaaaany times, but I can also ask David Coudert to check that tests pass, as he has them installed (well, CPLEX for sure and I do not know about Gurobi).
</p>
</blockquote>
<p>
That's probably a better idea; the refereeing process would look cleaner to me. We've been working on this stuff and there's a temptation to be hasty. I can read through the lines of your code & it can look good, but still miss things I can't test.
</p>
<blockquote class="citation">
<p>
But you really should try CPLEX once, it is soooooooooo much faster for integer problems ! <code>:)</code>
</p>
</blockquote>
<p>
Maybe. :) I don't want to have to download all these things over & over with each new release of Sage, which occurs far more frequently than I'd like. Though we seem to have been stuck at 4.8 for a surprisingly long time...!
</p>
TicketncohenFri, 13 Apr 2012 15:32:26 GMT
https://trac.sagemath.org/ticket/12823#comment:26
https://trac.sagemath.org/ticket/12823#comment:26
<blockquote class="citation">
<p>
Okay, I understand now, and I think it makes better sense, too. <code>;)</code> Duplicated code is one thing, like with the Gurobi, CPLEX, and Coin files. I don't think that's a problem, nor is it incompatible with using the one call in glpk, as I suggest. But I do think we should allow a backend to redefine <code>remove_constraint()</code> to take advantage of its own efficiency. In particular, glpk should be able to remove several constraints w/one function call, because it makes it possible. That doesn't duplicate code.
</p>
</blockquote>
<p>
Well, that is the only code I talk about then.
Ok, all in all, perhaps we should keep the code as it is. I really have no use for these *s methods, and to me they just take most of the file for nothing, but of course you are working on a different kind of problems.
</p>
<blockquote class="citation">
<p>
If you're okay with that, I think this is something that I could take care of today in generic_backend, glpk_backend, and coin_backed; then you could take care of the others.
</p>
</blockquote>
<p>
This time it is me who does not understand what you mean. What would you like to do in these files ?
My proposition was to remove the s functions and replace them by a generic function that would call the *[!s] functions many times, and you think that it is best to have them exposed. I think you are right, mainly because my main argument is "they are useless", and that if anybody think they are useful they immediately become so <code>:)</code>
</p>
<blockquote class="citation">
<p>
If you're not okay with that, then, yeah, it would be best to work this out in a different ticket.
</p>
</blockquote>
<p>
Well, this ticket is written and does the work we wanted it to do when you opened it. So I'd vote for getting it reviewed, then merged if that is ok with you <code>:)</code>
</p>
<blockquote class="citation">
<p>
That's probably a better idea; the refereeing process would look cleaner to me. We've been working on this stuff and there's a temptation to be hasty. I can read through the lines of your code & it can look good, but still miss things I can't test.
</p>
</blockquote>
<p>
No prob ! I sent him an email a couple of minutes ago, I hope he will have some time to deal with that <code>:)</code>
</p>
<blockquote class="citation">
<p>
Maybe. :) I don't want to have to download all these things over & over with each new release of Sage, which occurs far more frequently than I'd like. Though we seem to have been stuck at 4.8 for a surprisingly long time...!
</p>
</blockquote>
<p>
I am told Sage5.0 should be out soon. And I would like veryyyyyyyy much to see <a class="closed ticket" href="https://trac.sagemath.org/ticket/11880" title="enhancement: ISGCI in Sage (a Graph Classes database http://www.graphclasses.org/ ) (closed: fixed)">#11880</a> inside of it. This ticket is a nice addition too. Well, I personally got used to compiling Sage every week, but it quickly gets tricky when a user comes and says "This code does not work in 4.8, what should I do ?". Most of the time I have no idea what the code was like at this time <code>:)</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 17:37:23 GMT
https://trac.sagemath.org/ticket/12823#comment:27
https://trac.sagemath.org/ticket/12823#comment:27
<p>
Nathann,
</p>
<p>
I think there is a better implementation of removing constraints than the one we have right now, one that will avoid code duplication, as you say. Let me think about it this afternoon, and I will upload an alternate patch. This will give us something concrete to discuss.
</p>
<p>
Otherwise, I think we'll just keep confusing each other.
</p>
TicketncohenFri, 13 Apr 2012 17:41:23 GMT
https://trac.sagemath.org/ticket/12823#comment:28
https://trac.sagemath.org/ticket/12823#comment:28
<blockquote class="citation">
<p>
I think there is a better implementation of removing constraints than the one we have right now, one that will avoid code duplication, as you say. Let me think about it this afternoon, and I will upload an alternate patch.
</p>
</blockquote>
<p>
(at 19h40) This..... afternoon ? <code>:D</code>
</p>
<blockquote class="citation">
<p>
This will give us something concrete to discuss.
</p>
</blockquote>
<p>
Agreed ! <code>:)</code>
</p>
<blockquote class="citation">
<p>
Otherwise, I think we'll just keep confusing each other.
</p>
</blockquote>
<p>
Well, it is slow but even if it takes many exchanges we end up getting the idea through <code>:)</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 18:59:01 GMTattachment set
https://trac.sagemath.org/ticket/12823
https://trac.sagemath.org/ticket/12823
<ul>
<li><strong>attachment</strong>
set to <em>trac_12823_alternate_removal.patch</em>
</li>
</ul>
Ticketjohn_perryFri, 13 Apr 2012 19:03:53 GMTstatus, description changed
https://trac.sagemath.org/ticket/12823#comment:29
https://trac.sagemath.org/ticket/12823#comment:29
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>needs_info</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12823?action=diff&version=29">diff</a>)
</li>
</ul>
<p>
I've attached another patch that
</p>
<ul><li>removes <code>remove_constraints()</code> from <code>mip.pyx</code>,
</li><li>incorporates a generic <code>remove_constraints()</code> into <code>generic_backend.pyx</code>, more or less along the lines of what you were doing with CPLEX and gurobi, but
</li><li>retains the definitions of <code>remove_constraints()</code> used previously in <code>coin_backend.pyx</code> and <code>glpk_backend.pyx</code>, taking advantage of their respective optimizations.
</li></ul><p>
The CPLEX & Gurobi patch can be changed so that <strong>only</strong> <code>remove_constraint()</code> need be defined. If you prefer, we could rename that to <code>remove_single_constraint()</code>. This eliminates some code duplication, though not much. I think the tradeoff is worth the trouble, myself.
</p>
<p>
Oh  notice that I still have the old WARN:: and so on in there. I'll change it to the way you had it, if you're okay with this approach. I have a meeting now, but I wanted to get this out so you could look at it & consider it.
</p>
<p>
Or, we can stick with the older patches.
</p>
TicketncohenFri, 13 Apr 2012 20:07:17 GMT
https://trac.sagemath.org/ticket/12823#comment:30
https://trac.sagemath.org/ticket/12823#comment:30
<p>
Helloooooooo John !!
</p>
<p>
Thank you for this other patch ! I will update mine in a few seconds so that the remove_constraintS method disappear from Gurobi and CPLEX, but I would like very much to have a remove_constraint (no s) in mip.pyx. The most natural operation is to remove only one constraint, some of the persons who told me they needed such a feature actually edited LP manually and wanted to "do some tests", in which case the operation they would use the most is to remove only one constraint.
</p>
<p>
Nathann
</p>
TicketncohenFri, 13 Apr 2012 20:11:10 GMTattachment set
https://trac.sagemath.org/ticket/12823
https://trac.sagemath.org/ticket/12823
<ul>
<li><strong>attachment</strong>
set to <em>trac_12823cplex_gurobi.patch</em>
</li>
</ul>
TicketncohenFri, 13 Apr 2012 20:11:36 GMT
https://trac.sagemath.org/ticket/12823#comment:31
https://trac.sagemath.org/ticket/12823#comment:31
<p>
Patch updated, without remove_constraintS methods <code>:)</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryFri, 13 Apr 2012 21:48:02 GMT
https://trac.sagemath.org/ticket/12823#comment:32
https://trac.sagemath.org/ticket/12823#comment:32
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:30" title="Comment 30">ncohen</a>:
</p>
<blockquote class="citation">
<p>
...but I would like very much to have a remove_constraint (no s) in mip.pyx.
</p>
</blockquote>
<p>
Okay. I can add it, but it will have to wait until tomorrow, or maybe Monday (depending on how busy I am). If you want it sooner, you can add it to your ticket.
</p>
TicketdcoudertSat, 14 Apr 2012 23:45:39 GMT
https://trac.sagemath.org/ticket/12823#comment:33
https://trac.sagemath.org/ticket/12823#comment:33
<p>
Hello,
</p>
<p>
Nathann asks me to pass some tests. So I tried the patchs with sage5.0beta13
</p>
<p>
First, I don't understand the install messages.
</p>
<pre class="wiki">compote:~/pathtosage/devel/sagemyclone> hg qimport ~/Recherche/sagepatchs/trac_12823_const_for_obj_funs.patch
adding trac_12823_const_for_obj_funs.patch to series file
compote:~/pathtosage/devel/sagemyclone> hg qpush
applying trac_12823_const_for_obj_funs.patch
now at: trac_12823_const_for_obj_funs.patch
compote:~/pathtosage/devel/sagemyclone> hg qimport ~/Recherche/sagepatchs/trac_12823cplex_gurobi.patch
adding trac_12823cplex_gurobi.patch to series file
compote:~/Soft/sage5.0.beta13/devel/sagemyclone> hg qpush
applying trac_12823cplex_gurobi.patch
patching file sage/numerical/backends/gurobi_backend.pyx
Hunk #2 succeeded at 410 with fuzz 2 (offset 13 lines).
Hunk #3 succeeded at 418 with fuzz 1 (offset 13 lines).
Hunk #4 succeeded at 431 with fuzz 2 (offset 13 lines).
Hunk #7 succeeded at 785 with fuzz 1 (offset 12 lines).
now at: trac_12823cplex_gurobi.patch
</pre><p>
I don't have coin or gurobi, so I tried only glpk and cplex
</p>
<pre class="wiki">~/pathtosage/devel/sagemyclone>../../sage t optional sage/numerical/backends/cplex_backend.pyx
sage t optional "devel/sagemyclone/sage/numerical/backends/cplex_backend.pyx"
[1.2 s]

All tests passed!
Total time for all tests: 1.2 seconds
~/pathtosage/devel/sagemyclone>../../sage t optional sage/numerical/backends/glpk_backend.pyx
sage t optional "devel/sagemyclone/sage/numerical/backends/glpk_backend.pyx"
[1.1 s]

All tests passed!
Total time for all tests: 1.1 seconds
</pre><p>
Then I tried the alternate patch but it fails to apply
</p>
<pre class="wiki">compote:~/pathtosage/devel/sagemyclone> hg qapplied
compote:~/pathtosage/devel/sagemyclone> hg qimport ~/pathtopatchs/trac_12823_alternate_removal.patch
adding trac_12823_alternate_removal.patch to series file
compote:~/pathtosage/devel/sagemyclone> hg qpush
applying trac_12823_alternate_removal.patch
patching file sage/numerical/backends/generic_backend.pyx
Hunk #1 FAILED at 251
1 out of 1 hunks FAILED  saving rejects to file sage/numerical/backends/generic_backend.pyx.rej
patching file sage/numerical/mip.pyx
Hunk #1 FAILED at 1037
1 out of 5 hunks FAILED  saving rejects to file sage/numerical/mip.pyx.rej
patch failed, unable to continue (try v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh trac_12823_alternate_removal.patch
compote:~/pathtosage/devel/sagemyclone> hg qapplied
trac_12823_alternate_removal.patch
</pre><p>
generic_backend.pyx.rej is
</p>
<pre class="wiki"> generic_backend.pyx
+++ generic_backend.pyx
@@ 252,7 +252,15 @@
 ``constraints``  an iterable containing the indices of the rows to remove.
"""
 raise NotImplementedError()
+ if type(constraints) == int: self.remove_constraint(constraints)
+
+ cdef int c
+ cdef int last = self.nrows() + 1
+
+ for c in sorted(constraints, reverse=True):
+ if c != last:
+ self.remove_constraint(c)
+ last = c
cpdef add_linear_constraint(self, coefficients, lower_bound, upper_bound, name=None):
"""
</pre><p>
and mip.pyx.rej is
</p>
<pre class="wiki"> mip.pyx
+++ mip.pyx
@@ 1038,45 +1038,6 @@
self.add_constraint(functions[0]  functions[1], max=0, name=name)
self.add_constraint(functions[1]  functions[2], max=0, name=name)
 def remove_constraint(self, int i):
 r"""
 Removes a constraint from self.

 INPUT:

  ``i``  Index of the constraint to remove.

 EXAMPLE::

 sage: p = MixedIntegerLinearProgram()
 sage: x, y = p[0], p[1]
 sage: p.add_constraint(x + y, max = 10)
 sage: p.add_constraint(x  y, max = 0)
 sage: p.add_constraint(x  y, max = 0)
 sage: p.add_constraint(x, max = 4)
 sage: p.remove_constraint(2)
 sage: p.show()
 Maximization:
 <BLANKLINE>
 Constraints:
 x_0 + x_1 <= 10.0
 x_0  x_1 <= 0.0
 x_0 <= 4.0
 ...
 sage: p.number_of_constraints()
 3

 WARN::

 Whether the first constraint is numbered 0 or 1 depends on the backend.
 For GLPK, the first constraint has index 1; for Coin, it has index 0.
 This is why the example above adds the same constraint twice,
 and tries to remove on of its copies. Whether it removes the first
 or the second depends on the backend.
 Since supplying an invalid number WILL CAUSE A CRASH, please be careful!
 """
 self._backend.remove_constraint(i)

def remove_constraints(self, constraints):
"""
Remove several constraints.
</pre><p>
Hope it helps.
</p>
Ticketjohn_perrySun, 15 Apr 2012 02:14:14 GMT
https://trac.sagemath.org/ticket/12823#comment:34
https://trac.sagemath.org/ticket/12823#comment:34
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:33" title="Comment 33">dcoudert</a>:
</p>
<blockquote class="citation">
<p>
Nathann asks me to pass some tests. So I tried the patchs with sage5.0beta13
</p>
<p>
First, I don't understand the install messages.
</p>
</blockquote>
<p>
The first one is okay. The fuzz is due to the fact that I used a different edition of sage to create the patch.
</p>
<p>
The output of the second patch is problematic. FWIW, I can't install the patch on beta8, so apparently there's some dependency that needs to be listed.
</p>
<p>
I'm going to try and figure out the dependency, then get back to you. Hopefully I won't have to redo the patch.
</p>
Ticketjohn_perrySun, 15 Apr 2012 02:34:53 GMTdependencies, description changed
https://trac.sagemath.org/ticket/12823#comment:35
https://trac.sagemath.org/ticket/12823#comment:35
<ul>
<li><strong>dependencies</strong>
changed from <em>12833</em> to <em>#12220, #12833</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12823?action=diff&version=35">diff</a>)
</li>
</ul>
<p>
Looks like I goofed when creating the patch. Please apply <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/12823/trac_12823_const_for_obj_funs.patch" title="Attachment 'trac_12823_const_for_obj_funs.patch' in Ticket #12823">trac_12823_const_for_obj_funs.patch</a><a class="tracrawlink" href="https://trac.sagemath.org/rawattachment/ticket/12823/trac_12823_const_for_obj_funs.patch" title="Download"></a> first, then <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/12823/trac_12823_alternate_removal.patch" title="Attachment 'trac_12823_alternate_removal.patch' in Ticket #12823">trac_12823_alternate_removal.patch</a><a class="tracrawlink" href="https://trac.sagemath.org/rawattachment/ticket/12823/trac_12823_alternate_removal.patch" title="Download"></a>, and finally <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/12823/trac_12823cplex_gurobi.patch" title="Attachment 'trac_12823cplex_gurobi.patch' in Ticket #12823">trac_12823cplex_gurobi.patch</a><a class="tracrawlink" href="https://trac.sagemath.org/rawattachment/ticket/12823/trac_12823cplex_gurobi.patch" title="Download"></a>. I have modified the ticket description to reflect this.
</p>
<p>
I'm actually getting doctest errors on this, so I may upload new patches. But, if you don't get problems after this, that would suggest things are okay. I'm using an older beta, so I'm probably still missing something.
</p>
Ticketjohn_perrySun, 15 Apr 2012 02:39:01 GMT
https://trac.sagemath.org/ticket/12823#comment:36
https://trac.sagemath.org/ticket/12823#comment:36
<p>
No, I can't get <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/12823/trac_12823cplex_gurobi.patch" title="Attachment 'trac_12823cplex_gurobi.patch' in Ticket #12823">trac_12823cplex_gurobi.patch</a><a class="tracrawlink" href="https://trac.sagemath.org/rawattachment/ticket/12823/trac_12823cplex_gurobi.patch" title="Download"></a> to work, either. Alright, time to rework this.
</p>
Ticketjohn_perrySun, 15 Apr 2012 04:17:42 GMTstatus, description changed
https://trac.sagemath.org/ticket/12823#comment:37
https://trac.sagemath.org/ticket/12823#comment:37
<ul>
<li><strong>status</strong>
changed from <em>needs_info</em> to <em>needs_review</em>
</li>
<li><strong>description</strong>
modified (<a href="/ticket/12823?action=diff&version=37">diff</a>)
</li>
</ul>
<p>
The new patch should incorporate all the changes. It passes doctests on 5.0.beta8. It <strong>might</strong> depend on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12220" title="enhancement: Updated CBC spkg (closed: fixed)">#12220</a>; I'm not sure. The problems I encountered before were due to my having messed up my queue; I had popped too much, and <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/12823/trac_12823_alternate_removal.patch" title="Attachment 'trac_12823_alternate_removal.patch' in Ticket #12823">trac_12823_alternate_removal.patch</a><a class="tracrawlink" href="https://trac.sagemath.org/rawattachment/ticket/12823/trac_12823_alternate_removal.patch" title="Download"></a> included material from <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a>. Please review...
</p>
Ticketjohn_perrySun, 15 Apr 2012 05:03:44 GMTdependencies changed
https://trac.sagemath.org/ticket/12823#comment:38
https://trac.sagemath.org/ticket/12823#comment:38
<ul>
<li><strong>dependencies</strong>
changed from <em>#12220, #12833</em> to <em>#12220, #12736, #12833</em>
</li>
</ul>
<p>
It looks as if <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a> is a dependency now, due to some changes in function signatures. Sorry for not noticing that previously. I'm about to update another patch that accounts for some problems this has introduced.
</p>
Ticketjohn_perrySun, 15 Apr 2012 05:19:23 GMT
https://trac.sagemath.org/ticket/12823#comment:39
https://trac.sagemath.org/ticket/12823#comment:39
<p>
On <strong>sage5.0.beta8</strong>, I have the following patches applied <strong>first</strong>: trac_12220all_tests_pass.patch, trac_12220mad+doc.patch, trac_12220nocache.patch, trac_12736_more_solver_options_for_glpk.patch (and in that order!). Then I apply <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/12823/trac_12823_rolls_all_into_one.patch" title="Attachment 'trac_12823_rolls_all_into_one.patch' in Ticket #12823">trac_12823_rolls_all_into_one.patch</a><a class="tracrawlink" href="https://trac.sagemath.org/rawattachment/ticket/12823/trac_12823_rolls_all_into_one.patch" title="Download"></a>.
</p>
<p>
This now works for me on three different versions of sage. I have confirmed that it works with GLPK and Coin (using <code>sage t optional sage/numerical/backends/coin_backend.pyx</code>), so we need testing of CPLEX and Gurobi. Since Nathann added <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a> as a dependency due to some changes in Gurobi, I presume that this may also be required to test that.
</p>
TicketdcoudertSun, 15 Apr 2012 10:36:57 GMT
https://trac.sagemath.org/ticket/12823#comment:40
https://trac.sagemath.org/ticket/12823#comment:40
<p>
Hello,
</p>
<p>
I don't need patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12220" title="enhancement: Updated CBC spkg (closed: fixed)">#12220</a> since it is included in beta13.
</p>
<p>
I first tried to install patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a> and then this patch and it fails.
Then I realized that you have installed only half of patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a>. File trac_12736.patch is missing.
</p>
<p>
When I install trac_12736_more_solver_options_for_glpk.patch and then this patch, install is OK.
</p>
<p>
Can you udpate ths patch installing first patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12220" title="enhancement: Updated CBC spkg (closed: fixed)">#12220</a> (3 files) and patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a> (2 files).
</p>
<p>
D.
</p>
Ticketjohn_perrySun, 15 Apr 2012 14:45:04 GMT
https://trac.sagemath.org/ticket/12823#comment:41
https://trac.sagemath.org/ticket/12823#comment:41
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:40" title="Comment 40">dcoudert</a>:
</p>
<blockquote class="citation">
<p>
I don't need patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12220" title="enhancement: Updated CBC spkg (closed: fixed)">#12220</a> since it is included in beta13.
</p>
</blockquote>
<p>
Great.
</p>
<blockquote class="citation">
<p>
I first tried to install patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a> and then this patch and it fails.
Then I realized that you have installed only half of patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a>. File trac_12736.patch is missing.
</p>
</blockquote>
<p>
If that oversight wasn't embarrassing enough, I looked at it and found that it was a mere change in documentation that caused the problem.
</p>
<blockquote class="citation">
<p>
Can you udpate ths patch installing first patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12220" title="enhancement: Updated CBC spkg (closed: fixed)">#12220</a> (3 files) and patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a> (2 files).
</p>
</blockquote>
<p>
Done. Hopefully it will finally work. Third time's the charm, and all...
</p>
Ticketjohn_perrySun, 15 Apr 2012 15:31:07 GMT
https://trac.sagemath.org/ticket/12823#comment:42
https://trac.sagemath.org/ticket/12823#comment:42
<p>
I have it working on beta8 and beta9, two different systems, with GLPK and Coin 2.7.5.
</p>
TicketdcoudertSun, 15 Apr 2012 16:51:24 GMT
https://trac.sagemath.org/ticket/12823#comment:43
https://trac.sagemath.org/ticket/12823#comment:43
<p>
Ok, I'm now able to install successfully the patch !
</p>
<p>
Tests are OK with GLPK but not with CPLEX.
</p>
<pre class="wiki">sage t optional "devel/sagemyclone/sage/numerical/backends/cplex_backend.pyx"
IBM ILOG License Manager: "IBM ILOG Optimization Suite for Academic Initiative" is accessing CPLEX 12 with option(s): "e m b q ".
**********************************************************************
File "/pathtosage/devel/sagemyclone/sage/numerical/backends/cplex_backend.pyx", line 435:
sage: p.solve() # optional  CPLEX
Exception raised:
Traceback (most recent call last):
File "/pathtosage/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/pathtosage/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/pathtosage/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_9[10]>", line 1, in <module>
p.solve() # optional  CPLEX###line 435:
sage: p.solve() # optional  CPLEX
File "mip.pyx", line 1431, in sage.numerical.mip.MixedIntegerLinearProgram.solve (sage/numerical/mip.c:7747)
File "cplex_backend.pyx", line 854, in sage.numerical.backends.cplex_backend.CPLEXBackend.solve (sage/numerical/backends/cplex_backend.c:7823)
MIPSolverException: 'CPLEX: The problem is unbounded'
**********************************************************************
File "/pathtosage/devel/sagemyclone/sage/numerical/backends/cplex_backend.pyx", line 437:
sage: p.get_values([x,y]) # optional  CPLEX
Expected:
[0.0, 3.0]
Got:
[2.0, 0.0]
**********************************************************************
1 items had failures:
2 of 13 in __main__.example_9
***Test Failed*** 2 failures.
For whitespace errors, see the file /home/dcoudert/.sage//tmp/cplex_backend_17001.py
[1.2 s]

The following tests failed:
sage t optional "devel/sagemyclone/sage/numerical/backends/cplex_backend.pyx"
Total time for all tests: 1.2 seconds
</pre><p>
I have observed that <code></code>p.remove_constraint(0)<code></code> removes all constraints for the test example, hence the unbounded problem error.
</p>
<pre class="wiki">sage: p = MixedIntegerLinearProgram(solver='CPLEX')
IBM ILOG License Manager: "IBM ILOG Optimization Suite for Academic Initiative" is accessing CPLEX 12 with option(s): "e m b q ".
sage: x, y = p[0], p[1]
sage: p.add_constraint(2*x + 3*y, max = 6)
sage: p.add_constraint(3*x + 2*y, max = 6)
sage: p.set_objective(x + y + 7)
sage: p.set_integer(x); p.set_integer(y)
sage: p.show()
Maximization:
x_0 + x_1 + 7.0
Constraints:
2.0 x_0 + 3.0 x_1 <= 6.0
3.0 x_0 + 2.0 x_1 <= 6.0
Variables:
x_0 is an integer variable (min=0.0, max=+oo)
x_1 is an integer variable (min=0.0, max=+oo)
sage: p.solve()
9.0
sage: p.get_values([x,y])
[2.0, 0.0]
sage: p.remove_constraint(0)
sage: p.show()
Maximization:
x_0 + x_1 + 7.0
Constraints:
Variables:
x_0 is an integer variable (min=0.0, max=+oo)
x_1 is an integer variable (min=0.0, max=+oo)
</pre>
Ticketjohn_perrySun, 15 Apr 2012 17:12:18 GMT
https://trac.sagemath.org/ticket/12823#comment:44
https://trac.sagemath.org/ticket/12823#comment:44
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:43" title="Comment 43">dcoudert</a>:
</p>
<blockquote class="citation">
<p>
Ok, I'm now able to install successfully the patch !
</p>
</blockquote>
<p>
Finally! :)
</p>
<blockquote class="citation">
<p>
Tests are OK with GLPK but not with CPLEX.
</p>
</blockquote>
<p>
I miscopied a line from Nathann's patch. I've fixed that in the new patch; can you try the new one?
</p>
<p>
thx a lot
john
</p>
TicketdcoudertSun, 15 Apr 2012 19:10:57 GMT
https://trac.sagemath.org/ticket/12823#comment:45
https://trac.sagemath.org/ticket/12823#comment:45
<p>
That's much better ! now tests are ok for glpk_backend.pyx and cplex_backend.pyx.
I can't test coin or gurobi.
</p>
<p>
However, the following test fails:
</p>
<pre class="wiki">compote:/pathtosage/devel/sagemyclone> ../../sage t optional sage/numerical/mip.pyx
sage t optional "devel/sagemyclone/sage/numerical/mip.pyx"
IBM ILOG License Manager: "IBM ILOG Optimization Suite for Academic Initiative" is accessing CPLEX 12 with option(s): "e m b q ".
**********************************************************************
File "/pathtosage/devel/sagemyclone/sage/numerical/mip.pyx", line 1578:
sage: p.solver_parameter("CPX_PARAM_TILIM", 60) # optional  CPLEX
Exception raised:
Traceback (most recent call last):
File "/pathtosage/local/bin/ncadoctest.py", line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/pathtosage/local/bin/sagedoctest.py", line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example, filename, compileflags)
File "/pathtosage/local/bin/ncadoctest.py", line 1172, in run_one_example
compileflags, 1) in test.globs
File "<doctest __main__.example_29[4]>", line 1, in <module>
p.solver_parameter("CPX_PARAM_TILIM", Integer(60)) # optional  CPLEX###line 1578:
sage: p.solver_parameter("CPX_PARAM_TILIM", 60) # optional  CPLEX
File "mip.pyx", line 1599, in sage.numerical.mip.MixedIntegerLinearProgram.solver_parameter (sage/numerical/mip.c:8173)
File "glpk_backend.pyx", line 1525, in sage.numerical.backends.glpk_backend.GLPKBackend.solver_parameter (sage/numerical/backends/glpk_backend.cpp:9375)
KeyError: 'CPX_PARAM_TILIM'
**********************************************************************
1 items had failures:
1 of 9 in __main__.example_29
***Test Failed*** 1 failures.
For whitespace errors, see the file /home/dcoudert/.sage//tmp/mip_25176.py
[1.5 s]

The following tests failed:
sage t optional "devel/sagemyclone/sage/numerical/mip.pyx"
Total time for all tests: 1.5 seconds
</pre><p>
Sorry about that.
</p>
Ticketjohn_perrySun, 15 Apr 2012 20:03:01 GMT
https://trac.sagemath.org/ticket/12823#comment:46
https://trac.sagemath.org/ticket/12823#comment:46
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:45" title="Comment 45">dcoudert</a>:
</p>
<blockquote class="citation">
<p>
That's much better ! now tests are ok for glpk_backend.pyx and cplex_backend.pyx.
</p>
</blockquote>
<p>
Getting there!
</p>
<blockquote class="citation">
<p>
I can't test coin or gurobi.
</p>
</blockquote>
<p>
I've tested Coin. We need Nathann to test gurobi (and maybe he can test coin, too.)
</p>
<blockquote class="citation">
<p>
However, the following test fails:
</p>
</blockquote>
<p>
The error makes sense. and, it's easily fixed, I think. Let me know if the newest patch fixes it.
</p>
<blockquote class="citation">
<p>
Sorry about that.
</p>
</blockquote>
<p>
Quite the contrary: <strong>thank you very much! </strong> I just hope we finish this today!
</p>
TicketdcoudertSun, 15 Apr 2012 20:43:02 GMT
https://trac.sagemath.org/ticket/12823#comment:47
https://trac.sagemath.org/ticket/12823#comment:47
<p>
The tests are now OK.
</p>
<p>
I have also pass a tests on the entire sage/numerical directory, and only 3 tests are failing: coin_backend.pyx, gurobi_backend.pyx, and generic_backend.pyx.
</p>
<p>
almost done.
</p>
TicketdcoudertSun, 15 Apr 2012 20:45:57 GMTreviewer set
https://trac.sagemath.org/ticket/12823#comment:48
https://trac.sagemath.org/ticket/12823#comment:48
<ul>
<li><strong>reviewer</strong>
set to <em>David Coudert</em>
</li>
</ul>
Ticketjohn_perrySun, 15 Apr 2012 20:52:18 GMT
https://trac.sagemath.org/ticket/12823#comment:49
https://trac.sagemath.org/ticket/12823#comment:49
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:47" title="Comment 47">dcoudert</a>:
</p>
<blockquote class="citation">
<p>
I have also pass a tests on the entire sage/numerical directory, and only 3 tests are failing: coin_backend.pyx, gurobi_backend.pyx, and generic_backend.pyx.
</p>
<p>
almost done.
</p>
</blockquote>
<p>
When you run these tests, are you running as <code>sage t optional</code> or as <code>sage t</code>? These failures would make sense if you were running them as <code>sage t optional</code>. You should get <strong>no</strong> errors if you leave out <code>optional</code>.
</p>
TicketdcoudertSun, 15 Apr 2012 21:42:40 GMT
https://trac.sagemath.org/ticket/12823#comment:50
https://trac.sagemath.org/ticket/12823#comment:50
<p>
You are right:
</p>
<ul><li>I have no error when running sage t sage/numerical/
</li><li>I have errors with the optimal flag.
</li></ul>
Ticketjohn_perrySun, 15 Apr 2012 22:07:33 GMT
https://trac.sagemath.org/ticket/12823#comment:51
https://trac.sagemath.org/ticket/12823#comment:51
<p>
You mean <code>optional</code>, not <code>optimal</code> :)
</p>
<p>
Okay: now we just need Nathann to give it a positive review for Gurobi, and we're done!
</p>
TicketdcoudertSun, 15 Apr 2012 22:11:35 GMT
https://trac.sagemath.org/ticket/12823#comment:52
https://trac.sagemath.org/ticket/12823#comment:52
<p>
yes, optional ;)
</p>
TicketncohenMon, 16 Apr 2012 21:22:11 GMT
https://trac.sagemath.org/ticket/12823#comment:53
https://trac.sagemath.org/ticket/12823#comment:53
<p>
Hellooooooo !!
</p>
<p>
Sorry for the delay, I am in Austria these days and mostly backpacking, so it is pretty hard to find some time with both my computer and WiFI access <code>:)</code>
</p>
<p>
The point is that when I apply you folded patch (but I guess I should try to find out what it contains) I mostly get rejections. I applied before the two patch the current ticket says it depends on : <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a>.
</p>
<pre class="wiki">~/sage$ hg qimport http://trac.sagemath.org/sage_trac/rawattachment/ticket/12833/trac_12833.patch
hg qpush
adding trac_12833.patch to series file
~/sage$ hg qpush
applying trac_12833.patch
now at: trac_12833.patch
~/sage$ hg qimport http://trac.sagemath.org/sage_trac/rawattachment/ticket/12823/trac_12823_rolls_all_into_one.patch
hg qpush
adding trac_12823_rolls_all_into_one.patch to series file
~/sage$ hg qpush
applying trac_12823_rolls_all_into_one.patch
patching file sage/numerical/backends/gurobi_backend.pyx
Hunk #1 FAILED at 0
Hunk #2 FAILED at 23
Hunk #4 FAILED at 82
Hunk #5 FAILED at 101
Hunk #6 FAILED at 112
Hunk #7 FAILED at 125
Hunk #8 FAILED at 136
Hunk #9 FAILED at 190
Hunk #10 FAILED at 233
Hunk #11 FAILED at 244
Hunk #12 FAILED at 397
Hunk #13 FAILED at 405
Hunk #14 succeeded at 431 with fuzz 1 (offset 13 lines).
Hunk #15 FAILED at 427
Hunk #18 FAILED at 512
Hunk #19 FAILED at 537
Hunk #20 FAILED at 560
Hunk #21 FAILED at 601
Hunk #22 FAILED at 618
Hunk #23 FAILED at 730
Hunk #24 FAILED at 767
Hunk #25 FAILED at 1011
Hunk #26 FAILED at 1047
Hunk #27 FAILED at 1066
Hunk #28 FAILED at 1086
24 out of 28 hunks FAILED  saving rejects to file sage/numerical/backends/gurobi_backend.pyx.rej
patching file sage/numerical/mip.pyx
Hunk #8 FAILED at 455
Hunk #9 FAILED at 525
Hunk #12 FAILED at 591
Hunk #30 FAILED at 1571
4 out of 42 hunks FAILED  saving rejects to file sage/numerical/mip.pyx.rej
patch failed, unable to continue (try v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh trac_12823_rolls_all_into_one.patch
~/sage$ hg qapplied
trac_12736_more_solver_options_for_glpk.patch
trac_12736.patch
trac_12833.patch
trac_12823_rolls_all_into_one.patch
</pre>
Ticketjohn_perryMon, 16 Apr 2012 22:57:10 GMT
https://trac.sagemath.org/ticket/12823#comment:54
https://trac.sagemath.org/ticket/12823#comment:54
<p>
Nathann
</p>
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/12823#comment:53" title="Comment 53">ncohen</a>:
</p>
<blockquote class="citation">
<p>
Sorry for the delay, I am in Austria these days and mostly backpacking, so it is pretty hard to find some time with both my computer and WiFI access <code>:)</code>
</p>
</blockquote>
<p>
Hope you're having fun :)
</p>
<blockquote class="citation">
<p>
The point is that when I apply you folded patch (but I guess I should try to find out what it contains) I mostly get rejections. I applied before the two patch the current ticket says it depends on : <a class="closed ticket" href="https://trac.sagemath.org/ticket/12736" title="enhancement: More solver options for GLPK (closed: fixed)">#12736</a>, <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a>.
</p>
</blockquote>
<p>
I'm not surprised. I forgot to test it w/<a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a> first.
</p>
<p>
I can't get <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a> to apply at all on 5.0.beta9, so I'll have to try this at home, later tonight or tomorrow. Bummer. Stay tuned...
</p>
Ticketjohn_perryTue, 17 Apr 2012 05:04:18 GMTreviewer changed
https://trac.sagemath.org/ticket/12823#comment:55
https://trac.sagemath.org/ticket/12823#comment:55
<ul>
<li><strong>reviewer</strong>
changed from <em>David Coudert</em> to <em>David Coudert, Nathann Cohen</em>
</li>
</ul>
<p>
Okay. I downloaded & build beta 13 on a second computer (the first is a nearly 15 yearold, 32bit machine, bogged down in testing some other tickets), applied the requisite patches for <strong>all</strong> dependencies listed, and after a lot of tinkering, got it to work.
</p>
<p>
I then went back & figured out why beta 8 didn't like <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a>  some sort of whitespace error  and tested it there, since I have coin installed there. That works, too.
</p>
<p>
So Coin & GLPK work on my machines. Someone please test gurobi & cplex again!
</p>
<p>
An aside: most of the problems seem to have been caused by whitespace!!! Apparently <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a> fixes some whitespace problems in gurobi and mip that I had also tried to fix in the latest patch for this one. I hadn't tried to fix them before; hence the unpleasant surprise.
</p>
<p>
I hope this one works...
</p>
TicketncohenTue, 17 Apr 2012 06:17:32 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:56
https://trac.sagemath.org/ticket/12823#comment:56
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<p>
Hellooooooooooooo !!!
</p>
<p>
Well, this one seems well oiled <code>:)</code>
</p>
<pre class="wiki">~/sage/numerical/backends$ sage t optional coin_backend.pyx glpk_backend.pyx gurobi_backend.pyx cplex_backend.pyx
sage t optional "devel/sage2/sage/numerical/backends/coin_backend.pyx"
[1.2 s]
sage t optional "devel/sage2/sage/numerical/backends/cplex_backend.pyx"
[1.2 s]
sage t optional "devel/sage2/sage/numerical/backends/glpk_backend.pyx"
[1.2 s]
sage t optional "devel/sage2/sage/numerical/backends/gurobi_backend.pyx"
[1.4 s]

All tests passed!
Total time for all tests: 5.0 seconds
</pre><p>
And all tests pass in mip.pyx, graph, dgraph, generic_graph. Sooooo... I guess the patch is now positively reviewed <code>:)</code>
</p>
<p>
Nathann
</p>
Ticketjohn_perryTue, 17 Apr 2012 06:51:38 GMT
https://trac.sagemath.org/ticket/12823#comment:57
https://trac.sagemath.org/ticket/12823#comment:57
<p>
Yessss! :) It only took... uhm, how many tries? XD
</p>
TicketncohenTue, 17 Apr 2012 07:32:56 GMT
https://trac.sagemath.org/ticket/12823#comment:58
https://trac.sagemath.org/ticket/12823#comment:58
<p>
Ahahah.. Well, it is still funnier like that compared with times when it takes several months before a ticket gets reviewed <code>:)</code>
</p>
<p>
Nathann
</p>
TicketncohenTue, 17 Apr 2012 07:33:53 GMT
https://trac.sagemath.org/ticket/12823#comment:59
https://trac.sagemath.org/ticket/12823#comment:59
<p>
(This being said, the ticket still depends on <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a> <code>^^;</code>)
</p>
TicketdcoudertTue, 17 Apr 2012 07:48:16 GMT
https://trac.sagemath.org/ticket/12823#comment:60
https://trac.sagemath.org/ticket/12823#comment:60
<p>
Hello,
</p>
<p>
I don't need patch <a class="closed ticket" href="https://trac.sagemath.org/ticket/12833" title="defect: Crashes and doctests problems with Gurobi (closed: fixed)">#12833</a> to apply this patch and all tests are OK (sage t sage/numerical, and sage t optional sage/numerical/backends/glpk_backend.pyx and same for cplex).
So we could remove the dependency.
</p>
<p>
D.
</p>
TicketjdemeyerTue, 17 Apr 2012 22:23:43 GMTmilestone changed; work_issues deleted
https://trac.sagemath.org/ticket/12823#comment:61
https://trac.sagemath.org/ticket/12823#comment:61
<ul>
<li><strong>work_issues</strong>
<em>failing doctests</em> deleted
</li>
<li><strong>milestone</strong>
changed from <em>sage5.0</em> to <em>sage5.1</em>
</li>
</ul>
TicketjdemeyerMon, 07 May 2012 19:36:16 GMTauthor changed
https://trac.sagemath.org/ticket/12823#comment:62
https://trac.sagemath.org/ticket/12823#comment:62
<ul>
<li><strong>author</strong>
changed from <em>john_perry, ncohen</em> to <em>John Perry, Nathann Cohen</em>
</li>
</ul>
TicketjdemeyerMon, 07 May 2012 19:37:10 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:63
https://trac.sagemath.org/ticket/12823#comment:63
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
The patch needs a proper commit message.
</p>
TicketncohenWed, 09 May 2012 07:11:24 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:64
https://trac.sagemath.org/ticket/12823#comment:64
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
</ul>
TicketjdemeyerWed, 09 May 2012 09:45:28 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:65
https://trac.sagemath.org/ticket/12823#comment:65
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>needs_work</em>
</li>
</ul>
<p>
This needs to be rebased to sage5.0.rc0:
</p>
<pre class="wiki">applying /padic/scratch/jdemeyer/merger/patches/trac_12823_rolls_all_into_one.patch
patching file sage/numerical/mip.pyx
Hunk #16 FAILED at 809
Hunk #17 FAILED at 852
Hunk #19 FAILED at 969
3 out of 35 hunks FAILED  saving rejects to file sage/numerical/mip.pyx.rej
abort: patch failed to apply
</pre>
TicketncohenWed, 09 May 2012 10:28:05 GMTattachment set
https://trac.sagemath.org/ticket/12823
https://trac.sagemath.org/ticket/12823
<ul>
<li><strong>attachment</strong>
set to <em>trac_12823_rolls_all_into_one.patch</em>
</li>
</ul>
TicketncohenWed, 09 May 2012 10:31:17 GMTstatus changed
https://trac.sagemath.org/ticket/12823#comment:66
https://trac.sagemath.org/ticket/12823#comment:66
<ul>
<li><strong>status</strong>
changed from <em>needs_work</em> to <em>positive_review</em>
</li>
</ul>
<p>
Patch updated ! <code>;)</code>
</p>
<p>
Nathann
</p>
TicketjdemeyerWed, 23 May 2012 21:32:53 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/12823#comment:67
https://trac.sagemath.org/ticket/12823#comment:67
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage5.1.beta1</em>
</li>
</ul>
Ticket