#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 john_perry):
Replying to [comment:22 ncohen]:
> > Amusingly enough, I think `remove_constraint([1,2,3])` looks far more
odd than `remove_constraints([1])`.
>
> Ahahahah. What about remove_constraint(1) when you just have one
constraint to remove ? `:-D`
That looks perfectly fine. Did you mean `remove_constraints(1)`? That does
look odd, but not very much so.
> 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 add-variable(s),
add_linear_constraint(s), and now remove_constraint(s).
Okay.
> 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.
Well, in cases where the backend provides a way to add or remove multiple
rows at once (`glpk` for instance), we ought to do that instead, rather
than remove one at a time.
> 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.
>
> Does that sound like a bad idea to you ?
No, that sounds like what ought to be done.
Let me make sure I understand what you're saying: when code that we have
duplicated in `mip.pyx` can be moved to `generic_backend.pyx`, we should
do that. Prime candidates for this are `add_variable(s)`,
`add_linear_constraint(s)`, and `remove_constraint(s)`. We would not
actually remove the functions (yet) though we would deprecate them.
If I understand you correctly, here's my counter-proposal: 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
> > I don't understand why that makes it a mistake.
>
> 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 `:-)`
All you've said is that it's a mistake, only using different words! I
still don't understand why it's wrong.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12823#comment:23>
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.
