#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):
Helloooooo !!!
> 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.
I think "The Sage Way" would rather be something like "constraints()"
instead of "get_constraints()" and an optional parameter, n for example,
so that constraints(n = 10) returns constraint 10.
> This doesn't ''feel'' backend-ish to me.
Yeah, well. Sometimes, takes me one week to notice I've been stupid.
You're perfectly right.
> 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.
Right again. In my #687&%$ʯ of a head, they were exposed and useful in
the GenericBackend class. Which was stupid, there's no way it would hurt
to have them around in Python too.
> 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 hope we'll find a way to make this MILP class more useful to deal with
such problems. But you will have to explain them to me, your use cases are
very different `:-)`
> Here I think you're thinking I want this for #11606; that's not the
case.
> 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... `:-)`
Why not ? I will not need to understand it all, but just the part in which
the LP is generated. And "understanding" the LP isn't needed either, just
how it is built `:-)`
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11607#comment:7>
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.
