#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 john_perry):
Replying to [comment:5 ncohen]:
> 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.
Yay :-)
> 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 `:-)`
Actually, such a program might very well have counted the number of
constraints added to the program. :-)
In any case, we can add a method to obtain this information, say,
`number_of_constraints()`. We could go beyond this, and add to
`get_constraints()` an optional argument, `which_constraints`, which is a
list of constraints the user desires, rather than the entire list.
This doesn't ''feel'' backend-ish to me.
>
> > 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 don't see why they shouldn't be exposed. As for the aim, IMHO it's
always better to expose existing functionality that the user can use, at
least if the functionality is read-only.
In my particular case, I might need to extend the constraints of one
program by the constraints of another. This is probably not the only way
to implement what I need done, but it is ''one'' way. Currently, I do it
by building for each potential program a list of `libsingular` polynomials
that correspond to each constraint, discard the programs after testing
feasibility, then copying the equations of the best program into another
one, using the `coeff` command. It's a fabulous bottleneck. The problem
I'm working on generates a ''lot'' of programs.
(Notice I'm contradicting myself on efficiency -- I had forgotten how I
might use these methods.)
> > 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 ?
Either, but mostly time.
> Is it the idea of having a new element (the dictionary) attached to the
MILP structure that you find ugly ?
Here I think you're thinking I want this for #11606; that's not the case.
> ...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 `:-)`
I'm perfectly open to any suggestions you might have; maybe we should take
the discussion of the actual problem I'm working on into private email? I
can send you a copy of the relevant sage code, but I don't know if you
want to look at this monstrosity... `:-)`
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11607#comment:6>
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.
