#11607: read constraints from linear program
----------------------------------+-----------------------------------------
Reporter: john_perry | Owner: ncohen
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-4.7.2
Component: linear programming | Keywords: sd32
Work_issues: | Upstream: N/A
Reviewer: | Author: john_perry
Merged: | Dependencies:
----------------------------------+-----------------------------------------
Comment(by ncohen):
Replying to [comment:4 john_perry]:
> Replying to [comment:3 ncohen]:
> In my case, I have a program that generates constraints based on a
polynomial system. I don't personally know what the constraints are, and
in fact I want to read the generated constraints. For example, I might
want to check in some easy circumstances that the program is generating
the correct constraints.
I agree that in this case the MILP class should give you an easy way to
check that, and to this end your get_constraints() method is a perfectly
good answer. I still feel that the row(int index) and row_bounds(int
index) feel more like backend methods, as they require an information that
the user does not have : the indices of the rows. Even the number of
constraints is not available right now `:-)`
> Would that be immediately accessible to someone who has a
`MixedIntegerLinearProgram` object?
No, in this case it would not, but this is my point exactly : should such
functions be exposed, and if so in which aim ?
> I didn't necessarily want the overhead of a dictionary. I could see
adding that functionality, but if I were running a program where
efficiency might be of some concern, generating a dictionary every time I
do this seems a bit much.
When you talk of overhead, do you have memory or time in mind ? I do not
think the memory cost would be that important, but as you repeatedly want
to check for the existence of a given constraint, the "Set" structure
which yields a log(n) check for existence seems more fitting than linearly
exploring the cases each time a constraint is added.
Is it the idea of having a new element (the dictionary) attached to the
MILP structure that you find ugly ? I have to admit it's not that sexy...
To be perfectly frank I do not think it should be the MILP class' job to
check whether the given set of constraints could be simplified, my way of
doing it would be to build myself the set of constraints, which I would
then use to build the LP (this would require the definition of __hash__
functions for several MILP-related classes). But then I try to keep in
mind that we have different applications in mind, and that it can make
much better sense in your situation `:-)`
If you think this would be a nice feature of the MILP class, however, I do
think the dictionary trick is the best way to write it. `:-)`
Nathann
>
> Does that seem reasonable to you, or do you think I should generate the
dictionary anyway? Efficiency here isn't an actual concern of mine at the
moment, and might never be.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11607#comment:5>
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.
