We present a computational evaluation of existing and novel approaches
for the so-called Minimum Cost Linear Extension problem (MCLE). Given a
partially ordered set
A partially ordered set (or simply, a poset) is a pair
-
$x \leq y, ;; y \leq z ; \Rightarrow ; x \leq z, ;; \forall : x,y,z \in E$ ; -
$x \leq x, ;; \forall : x \in E$ ; -
$x \leq y, ;; y \leq x ; \Rightarrow ; x=y, ;; \forall : x,y \in E$ .
In a partial order
The Hasse diagram of a finite poset
Is is a well-known fact that every poset admits at least one linear
extension. Consider a linear extension
where
Let
By slightly abusing notation, we will write the total cost of a linear extension ${\mathbf L}={ x_{1} <{\mathbf L} x{2} <{\mathbf L} \ldots <{\mathbf L} x_{n}}$ as
Given a poset
The MCLE was originally defined in @Liu and further studied in @Wu. In
@Liu the authors showed that the MCLE generalizes the so-called bump
number and jump number problems on posets. Specifically, if we define
While discussing the algorithms described in this work, we shall assume
that the computational representation of a poset
In what folows we describe the greedy algorithm proposed by Liu et al. in @Liu, referred to as “Algorithm 2” in their paper. Here we provide a somewhat different description than the one given in the original paper. The reason for that is that we believe our description focus more closely on the conceptual steps, rather than on implementation choices.
For the sake of simplifying the presentation of algorithm
Liu2, we shall define the operation of
injecting an element into a partial linear
extension of a poset
-
The resulting linear order
$\mathbf{L'}$ is consistent with${\mathbf P}$ (i.e.,$x \leq_{\mathbf{L'}} y$ whenever$x \leq y$ in$\mathbf{P}$ ); -
$c(\mathbf{L'})$ is minimum.
In other words, we want to add
Obviously, some of these positions might be invalid, as they might not
be consistent with the order relations in
rl
**Input: & Cover graph
**Output: & Linear extension
& ****
**1. & Let
**2. & Let
**3. & while
**4. & ********
Select
**5. & **
Inject
**6. & end
**
[Liu2Pseudocode]
It is interesting to note that the Liu2 algorithm was presented in @Liu as a “greedy approximation algorithm.” We believe that the authors meant by it that the algorithm is a greedy procedure that produces solutions whose objective function values are typically (but not provably) close to the optimal value, what is a departure from the standard concept of an approximation algorithm. Indeed, as we argue below, it is possible to devise examples for which the solution produced by the algorithm is arbitrarily large (in terms of objective function value), as compared to the actual minimum.
The Liu2 algorithm does not have a fixed approximation rate.
Consider the poset
where
p4.7cmp4.7cmp4cm &
&
(a) Solution produced by algorithm Liu2; cost =
[figLiu2]
The application of algorithm Liu2 to
A topological sort of a directed acyclic graph
It is, therefore, natural to consider an algorithm for the MCLE which is
based on a topological sorting algorithm. One of the standard algorithms
for topologically sorting the vertices of a directed acyclic graph is
essentially a graph traversal procedure and can be implemented to run in
Since the MCLE accounts for possibly different costs associated with
pairs of incomparable adjacent elements in the ordering, the standard
algorithm for topological sorting must be modified in order to reflect
that cost structure. A straightforward variant of the algorithm can be
obtained by applying a greedy criterion to break ties whenever there are
two or more elements with zero out-degree. At the first iteration, the
algorithm arbitrarily selects a vertex with zero out-degree. From the
second iteration and on, let
We are now ready to present the pseudocode for the greedy topological sorting algorithm (see Figure [GTSAlgo]).
rl
**Input: & Cover graph
**Output: & Linear extension
& ****
**1. &
**2. & while
**3. & ******
**4. & **
Arbitrarily select
**5. & **
**6. & **
**7. & **
**8. & **
Update out-degrees of vertices in
**9. & **
**10. & end
**
[GTSAlgo]
The topological sorting heuristic GreedyTopSort runs in
Note that the set
More sophisticated greedy schemes can definitely be devised. In particular, criteria that incorporate look-ahead features might prove to be a better compromise between running time and solution quality. We chose to test this simpler version due to its relatively modest time complexity and as a way of initially assessing the quality of a topological sorting-based heuristic, as compared to the greedy algorithm of @Liu.
The basic components of a constraint programming model are a set of decision variables, their specific domains, and a set of constraints on those variables. A search engine is responsible for systematically assigning values to decision variables and performing a process of propagation, by means of which the data from the model’s constraints is used to further restrict the domains of unassigned variables. These steps are repeated up to the point when the domain of every variable has been restricted to a single value. At that moment, a feasible solution has been produced. Below we decribe a constraint programming model for the MCLE problem, along with the strategy applied by the constraint solver we utilized, in order to obtain an optimal solution – rather than enumerating all possible feasible assignments.
We modeled the MCLE problem by defining decision variables associated to
the vertices of the directed graph
The arcs in graph
In order to model the objective function we need to account for the cost
associated with each pair of incomparable elements which happen to be
adjacent in the linear extension, i.e., the cost
D$_{x,y}$ = pos[
, e$_{x,y} \in {0,1}$,
where count(
Now, defining the objective function is a matter of adding up the costs
for those incomparable pairs
We implemented the model in C++ with the use of Gecode @Gecode, a state-of-the-art constraint solver, which, in addition to the standard constraint satisfaction search engine, is equipped with a branch-and-bound module, allowing for an automatic search for optimal solutions satisfying the underlying model.
An optimal solution to the problem is obtained with the definition of
the objective function ObjFcn and a special method, called
constrain. Whenever an incumbent solution
We evaluated the two heuristic algorithms GreedyTopSort and Liu2 on a number of randomly generated instances of the MCLE problem. For a small subset of the instances, we were also able to run the exact constraint-based model (instances with more than 20 vertices demanded an excessive running time and were, therefore, excluded from the experiments). The results of the exact model are particularly important, as they provide information on how close to being optimal the heuristic solutions are (with respect to objective function value).
Instances were created with a special-purpose generator implemented in
C++. The generator makes use of the standard procedure for generating
random graphs: given a positive integer
Table [TableSmall] presents the solution values and running times of the
two heuristics on a set of “small” instances, consisting of posets with
a number
The heuristics are referred to in the table as GTS (short
for GreedyTopSort), Liu2 and CP
(short for “constraint programming model”). Columns 3-5 correspond to
the average running times of each algorithm on the three instances with
the corresponding values of
[hptb]
cc|rrr|rr|r & & &
10 & 0.2 & <0.01 & <0.01 & <0.01 & 191.7 & 100.0 & 191.7
20 & 0.2 & <0.01 & 0.03 & 0.02 & 138.4 & 100.0 & 138.4
30 & 0.2 & 0.01 & 0.09 & — & — & — & 184.0
40 & 0.2 & 0.01 & 0.21 & — & — & — & 157.7
50 & 0.2 & 0.02 & 0.40 & — & — & — & 43.5
60 & 0.2 & 0.03 & 0.69 & — & — & — & 137.8
70 & 0.2 & 0.04 & 1.13 & — & — & — & 155.4
80 & 0.2 & 0.05 & 1.69 & — & — & — & 158.2
& **158.4
& & &
10 & 0.4 & <0.01 & <0.01 & 0.02 & 179.9 & 154.6 & 122.4
20 & 0.4 & <0.01 & 0.02 & 0.44 & 165.4 & 136.1 & 115.1
30 & 0.4 & 0.01 & 0.07 & — & — & — & 169.3
40 & 0.4 & 0.01 & 0.16 & — & — & — & 148.6
50 & 0.4 & 0.02 & 0.32 & — & — & — & 126.4
60 & 0.4 & 0.02 & 0.53 & — & — & — & 119.2
70 & 0.4 & 0.03 & 0.89 & — & — & — & 119.2
80 & 0.4 & 0.04 & 1.33 & — & — & — & 127.6
& **131.0
& & &
10 & 0.4 & <0.01 & <0.01 & 0.05 & 164.6 & 199.0 & 84.6
20 & 0.4 & <0.01 & 0.02 & 186.22 & 198.6 & 209.2 & 105.4
30 & 0.4 & 0.01 & 0.05 & — & — & — & 126.3
40 & 0.4 & 0.01 & 0.13 & — & — & — & 92.3
50 & 0.4 & 0.01 & 0.21 & — & — & — & 123.1
60 & 0.4 & 0.02 & 0.37 & — & — & — & 110.8
70 & 0.4 & 0.02 & 0.53 & — & — & — & 112.0
80 & 0.4 & 0.03 & 0.83 & — & — & — & 107.2
& **107.7
& & &
10 & 0.8 & <0.01 & <0.01 & 0.50 & 225.1 & 216.6 & 107.9
20 & 0.8 & <0.01 & 0.01 & 31,464.60 & 312.1 & 264.0 & 117.7
30 & 0.8 & <0.01 & 0.03 & — & — & — & 85.2
40 & 0.8 & 0.01 & 0.06 & — & — & — & 84.1
50 & 0.8 & 0.01 & 0.11 & — & — & — & 85.3
60 & 0.8 & 0.01 & 0.18 & — & — & — & 69.7
70 & 0.8 & 0.02 & 0.28 & — & — & — & 111.2
80 & 0.8 & 0.02 & 0.41 & — & — & — & 83.1
& **93.0\
[TableSmall]
Table [TableLarge] presents similar data concerning solution values and running times of the two heuristics on “large” instances – those with a number of vertices varying from 100 to 1,000. Columns 3-4 are average running times over three instances, while column 5 has the same meaning as column 8 of Table [TableSmall].
[hbt]
cc
cc|rr|r & &
& & Obj.Fcn.
100 & 0.2 & 0.07 & 3.19 & 154.3
200 & 0.2 & 0.29 & 25.48 & 159.6
300 & 0.2 & 0.62 & 83.61 & 139.4
400 & 0.2 & 1.08 & 194.82 & 142.0
500 & 0.2 & 1.68 & 380.38 & 149.9
750 & 0.2 & 3.76 & 1,278.56 & 139.0
1,000 & 0.2 & 6.66 & 3,031.05 & 137.6
& **146.0
& &
& & Obj.Fcn.
100 & 0.4 & 0.06 & 2.31 & 173.7
200 & 0.4 & 0.22 & 18.37 & 125.4
300 & 0.4 & 0.48 & 61.98 & 139.6
400 & 0.4 & 0.84 & 146.20 & 135.8
500 & 0.4 & 1.31 & 285.12 & 139.8
750 & 0.4 & 2.92 & 960.87 & 132.0
1,000 & 0.4 & 5.18 & 2,274.18 & 137.1
& **140.5\
&
cc|rr|r & &
& & Obj.Fcn.
100 & 0.6 & 0.04 & 1.54 & 141.1
200 & 0.6 & 0.16 & 12.15 & 105.6
300 & 0.6 & 0.34 & 40.93 & 120.4
400 & 0.6 & 0.60 & 97.10 & 112.4
500 & 0.6 & 0.93 & 189.56 & 107.3
750 & 0.6 & 2.05 & 639.78 & 117.3
1,000 & 0.6 & 3.64 & 1,513.18 & 110.2
& **116.3
& &
& & Obj.Fcn.
100 & 0.8 & 0.03 & 0.76 & 91.2
200 & 0.8 & 0.10 & 5.99 & 81.3
300 & 0.8 & 0.21 & 20.20 & 82.3
400 & 0.8 & 0.36 & 48.00 & 98.0
500 & 0.8 & 0.54 & 93.86 & 91.1
750 & 0.8 & 1.18 & 316.72 & 92.0
1,000 & 0.8 & 2.10 & 751.06 & 90.4
& **89.5\
[TableLarge]
It can seen from Table [TableSmall] that GTS outperforms
Liu2 substantially when it comes to running time. On the
other hand, Liu2 performs better, with respect to objective
function value, than GTS in most cases. In fact, this is
true for instances with
In Table [TableLarge], the running time of GTS remains very
low. Indeed, it is sometimes several orders of magnitude lower than that
of Liu2. Here it is important to highlight the fact that
the algorithms’ implementations are homogenized, in the sense that the
two programs share as much code and data structures as possible.
Regarding the objective function of the heuristic solutions, we can see
a similar trend to the one present in the Table [TableSmall]: algorithm
Liu2 obtains better objective function values for instances
with
In this paper, we presented two novel solution approaches for the so-called Minimum Cost Linear Extension problem (MLCE): a topological sorting-based heuristic and a constraint programming model. We revisited an existing greedy algorithm for the MCLE, due to Liu et al. @Liu, and showed that their algorithm is not an approximation one, as originally suggested in their paper.
We also carried out a number of computational experiments on randonly
generated posets and reported on the relative performance of the three
procedures, which shows a clear trend as we vary the density of the
posets. The constraint programming approach was unable to compute
provably optimal solutions for posets with more than 20 elements
(
99
L. Bianco, P. Dell’Olmo, S. Giordani, An optimal algorithm to find the jump number of partially ordered sets, Computational Optimization and Applications, 8(2):197-210, 1997.
V. Bouchitte, M. Habib, NP-Completeness properties about linear extensions, Order 4:13-154, 1987.
Gecode Team, Gecode: Generic Constraint Development
Environment, Available from http://www.gecode.org
, 2006.
L. Liu, B. Wu, E. Yao, Minimizing the sum cost in linear extensions of a poset, J. Comb. Optim. 21:247-253, 2009.
B. Wu, E. Yao, L. Liu, A polynomially solvable case of optimal linear extension problem of a poset, J. Comb. Optim. 20:422-428, 2010.