#13205: make LP return bounds on variables
--------------------------------------+-------------------------------------
Reporter: dimpase | Owner: ncohen
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-5.2
Component: linear programming | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: #13148 | Stopgaps:
--------------------------------------+-------------------------------------
Comment (by ncohen):
> I pondered this question deeply :–) No, it's bad enough that
{{{p.get_max(v[9999999])}}} will always create {{{v[9999999]}}} if it does
not exist, instead of throwing {{{ValueError}}}, while
{{{p.get_max(9999999)}}} will throw {{{ValueError}}}.
I know it's ugly, but consider all the LP that only work this way.
Honestly, having to declare the variables first would really be a huge
mess.
> I'd really prefer this two-tier approach, when user-defined variables
and solver variables are kept apart interface-wise.
Yeah, but then again it would mean that we need to have two copies of each
command, according to how the data is given...
Actually, do you really need to work with MixedIntegerLinearProgam ? It
looks like all you want is to access the backend's methods directly, and
this you can do if you just deal with GenericBackend.
What about just working with this, and adding to it what you miss from
MixedIntegerLinearProgram ?
> By the way, it also looks strange that {{{v}}} doesn't even know its
(I)LP. Or can it be in several LPs at the same time?
Well, you can mess up with two instances of MixedIntegerLinearProgram so
badly that they would have common variables, and this would work, but that
would just be for the show `:-D`
Some time ago I think the variables knew about their LP, but because the
LP also knew about the variables it produced a cyclic reference, and
Python had to be forced to deallocate the two elements -- I think we
removed that not so long ago, while dealing with Cliquer's many memory
leaks. Which are fixed in a patch, btw `:-)`
Nathann
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13205#comment:9>
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.
