#12823: Allow constants for objective function & deletion of rows in
MixedIntegerLinearProgram
--------------------------------------+-------------------------------------
Reporter: john_perry | Owner: ncohen
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.0
Component: linear programming | Resolution:
Keywords: solver objective | Work issues: failing doctests
Report Upstream: N/A | Reviewers:
Authors: john_perry, ncohen | Merged in:
Dependencies: 12833 | Stopgaps:
--------------------------------------+-------------------------------------
Comment (by ncohen):
> Okay, I understand now, and I think it makes better sense, too. `;-)`
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 `remove_constraint()` 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.
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.
> 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.
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 `:-)`
> If you're not okay with that, then, yeah, it would be best to work this
out in a different ticket.
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 `:-)`
> 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.
No prob ! I sent him an email a couple of minutes ago, I hope he will have
some time to deal with that `:-)`
> 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...!
I am told Sage-5.0 should be out soon. And I would like veryyyyyyyy much
to see #11880 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 `:-)`
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12823#comment:26>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
