#18871: MILP formulation for cutwidth
-------------------------+-------------------------------------------------
Reporter: | Owner:
dcoudert | Status: needs_work
Type: | Milestone: sage-6.8
enhancement | Resolution:
Priority: major | Merged in:
Component: graph | Reviewers: Nathann Cohen
theory | Work issues:
Keywords: | Commit:
cutwidth, MILP | 802fe71e5ec2b12143ff8adb60c66549b443cd57
Authors: David | Stopgaps:
Coudert |
Report Upstream: N/A |
Branch: |
public/18871 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by dcoudert):
> - Module's doc, documentation of MILP variable `z`: at the end of the
line there
> is a `y^y`. Shouldn't it be `y^k`?
Right.
> - Constraints: the third constraint is missing one side of the
inequality.
Added
> - But I am not sure that I understand the system: why wouldn't you say
that:
> a) `x_v^k <= x_v^{k+1}` (the values can only increase)
> b) `\sum_v x_v^k == k` (for every k)
Constraint (a) can be rewritten with a sum as I did. It is sometimes
faster for the solver. Don't know why.
> - About y: what about only having those two constraints:
> - `y_{uv}^k >= x_v^k - x_u^k`
> - `y_{uv}^k >= x_u^k - x_v^k`
> It seems to me that they are sufficient to express {{{y_{uv}^k >=
x_u^k XOR x_v^k}}}. And you do not really need to say that `y` has to be
*equal* to the
> XOR, the `>=` should be enough given that you minimize the cost of a
cut.
You are right. I have simplified the code.
> - If you see a better way to name the `x,y`, and `z`... `:-P`
unfortunately no better names in mind.
> - When building the documentation, the references toward the number of
the
> constraints do not appear correctly. Neither does the 'xor'.
Corrected. (and no xor anymore)
> - You call `set_binary` on a variable that you already defined as
binary.
removed.
> - Is there any reason why you catch the `MIPSolverException`?
Removed. no particular reason.
> - You do not have to int+round the value of `z['z']`. The solver should
give you
> an integer value as you defined the variable as integral: if it does
not,
> that's a bug that should be fixed.
I have removed the round.
Thanks for the review.
--
Ticket URL: <http://trac.sagemath.org/ticket/18871#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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
