#605 closed defect (invalid)
Overflow in Optimal Cost
Reported by: | mgara | Owned by: | Alpar Juttner |
---|---|---|---|
Priority: | major | Milestone: | LEMON 1.4 release |
Component: | core | Version: | hg main |
Keywords: | Cc: | ||
Revision id: |
Description
Motivation ==========
Please consider the following simple class of problems (which I will refer to as the primal MRF problem [1]):
max_{x,r} c' r
wrt
r = |Ax - b|
where A is a network/graph matrix (the rows define the oriented edges, the matrix is Totally Unimodular), and c >= 0, b are integral vectors. The dual of this problem is an instance of an MCF problem defined on a graph represented by the network matrix A with b as the costs of the edges and c as the capacities. Strong duality holds here.
In our work, we are interested in examining and evaluating different approaches to solving either the MRF or MCF problem using either primal, dual or primal-dual methods. The context we have in mind is application to image processing tasks, in particular we are interested in the phase unwrapping problem in InSAR.
Properties of MCF Instances ===========================
- The MCF dual problem of the MRF problem is defined on the same graph as
defined by A, with the addition of an opposite arc with negative cost for every oriented arc in A.
- The MCF dual problem has no node imbalances by definition. The network flow
condition must still be enforced.
- By corollary of 1 & 2, the optimal values for the MCF dual problem must be
negative.
Current Issue with Lemon: =========================
Please consider the attached code that was tested with Lemon version 1.3.1. It should be self contained and compilable with the make command if the LEMON_HOME directory is correctly set in the Makefile.
Once compiled it can be run as follows (assuming a linux environment with a BASH shell) to reproduce the issue.
for scale in $(seq .1 .1 .4); do ./lemon_mcf_solver netgen_8_08a.txt $scale; done > output.txt
In output.txt we should see that as we scale the costs b by a factor of .1 - .4 smoothly we get a negative optimal value initially, but when we reach .4 we obtain a positive optimal value:
grep "simplex cost:\|scaling costs" output.txt
INFO: scaling costs by 0.100000 INFO: network simplex cost: -575280232 INFO: scaling costs by 0.200000 INFO: network simplex cost: -1154018674 INFO: scaling costs by 0.300000 INFO: network simplex cost: -1732004546 INFO: scaling costs by 0.400000 INFO: network simplex cost: 1984124216
Given property 3 of these MCF instances we know that positive cost solution is impossible to these MCF instances. In fact, we've verified that the solution is correct up to scale .3 (by comparing with other solvers) and around the scale of .4 is when we hit this issue.
We came across this issue by modifying some NETGEN instances to have the properties of the MCF dual problem we expect.
Please let us know if this is an issue with how we are using the Lemon library, or perhaps if this is a bug in the Lemon library that can be addressed.
Thank you in advance, Matt
[1] Kolmogorov, Vladimir. "Primal-dual algorithm for convex Markov random fields." Microsoft Research MSR-TR-2005-117 (2005).
Attachments (1)
Change History (5)
Changed 2 years ago by
Attachment: | lemon_issue.tar.gz added |
---|
comment:1 Changed 2 years ago by
Having just a short look at the code, I believe it is not a bug, but indeed just a simple integer overflow.
You use long long int
weights and costs, but use the default settings of solvers which are int
s.
Try to use
CapacityScaling<lemon::ListDigraph, long long int>
,
lemon::CostScaling<lemon::ListDigraph, long long int>
and
lemon::NetworkSimplex<lemon::ListDigraph, long long int>
Note that
- The above MCF implementations even allow using different data types for the capacity and for the cost calculation (see the doc).
- Using
long long int
type for the capacity and (even more importantly) for the costs makes sense even if the input consists of 32bit integers only. During the calculations capacity values are added together, and the cost values are multiplied with capacity values and added together, which can easily cause integer overflow.
comment:2 Changed 2 years ago by
I agree. You should use long long int
type as described above.
Furthermore, note that the total flow cost may not fit in the data type used for internal calculations of the algorithm. That's why the totalCost()
method has its own template argument. You can use it like this:
long long int totalCost1 = ns.totalCost(); double totalCost2 = ns.totalCost<double>();
See the documentation here: http://lemon.cs.elte.hu/pub/doc/1.3.1/a00276.html#a4e1efd04a6b234645d1ca18d2635d57e
comment:3 Changed 2 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:4 Changed 2 years ago by
Thank you for the information; we've tested that this actually fixes things and so we are continuing our benchmarking and testing. Thanks again and sorry for the mix-up.
Reproducible Code Example