From 85a07a091764c9bb66f05e98927f41583ede1619 Mon Sep 17 00:00:00 2001
From: Florent Jaillet
Date: Thu, 8 Feb 2018 14:30:30 +0100
Subject: [PATCH] Performing acceleration only after checking domination to
improve performance

src/main.hpp  2 +
src/mincoversetcomputer.cpp  41 ++++++++++++++++++++++
src/mincoversetcomputer.hpp  17 ++++++++
tests/tests_main.cpp  4 ++
4 files changed, 37 insertions(+), 27 deletions()
diff git a/src/main.hpp b/src/main.hpp
index 9a5fd03..e8ee2b5 100644
 a/src/main.hpp
+++ b/src/main.hpp
@@ 43,7 +43,7 @@
#include "mincoversetcomputer.hpp"
#define VERSION_NUMBER "1.0.2" ///< Version number of the application
+#define VERSION_NUMBER "1.0.3" ///< Version number of the application
/**
* \brief Set of flags parametrizing the output sent to stdout by the
diff git a/src/mincoversetcomputer.cpp b/src/mincoversetcomputer.cpp
index 374619e..8ed0ed7 100644
 a/src/mincoversetcomputer.cpp
+++ b/src/mincoversetcomputer.cpp
@@ 92,28 +92,35 @@ void MinCoverSetComputer::monotone_pruning(const MonotonePruningParam& param) {
tmp_marking.add_omegaless_marking(
mapping_diff_[candidate.ind_transition]);
 // NOTE: The following lines allow to choose between
 // MinCoverSetComputer::accelerate() and OrderedTuples::accelerate()
 // to perform the acceleration step. Note that both functions are not
 // exactly equivalent (see the documentation of
 // OrderedTuples::accelerate() for more details).
 // Note also that neither of the two functions exactly implements the
 // acceleration described in the reference paper, as the acceleration is
 // done inplace here (see the documentation of
 // MinCoverSetComputer::monotone_pruning() for more details).
 if (param.use_orderedtuples_for_accelerate) {
 p_curr_node_>mark_ancestors();
 ord_tuples_.accelerate(tmp_marking);
 } else {
 accelerate(p_curr_node_, tmp_marking);
 }
 ++computation_stats_.nb_accelerated;

param.bfs_traversal ? wait_.pop_front() : wait_.pop_back();
if (!(param.use_orderedtuples_for_is_dominated ?
ord_tuples_.is_dominated(tmp_marking) :
is_dominated(tmp_marking, p_root_))) {
+ // NOTE: To improve the processing speed of this implementation,
+ // the following acceleration is only done after checking the condition
+ // above.
+ // Note that this differs from what is described in the reference paper
+ // where the acceleration is systematically done before checking the
+ // condition.
+
+ // NOTE: The following lines allow to choose between
+ // MinCoverSetComputer::accelerate() and OrderedTuples::accelerate()
+ // to perform the acceleration step.
+ // Note that both functions are not exactly equivalent (see the
+ // documentation of OrderedTuples::accelerate() for more details).
+ // Note also that neither of the two functions exactly implements the
+ // acceleration described in the reference paper, as the acceleration
+ // is done inplace here (see the documentation of
+ // MinCoverSetComputer::monotone_pruning() for more details).
+ if (param.use_orderedtuples_for_accelerate) {
+ p_curr_node_>mark_ancestors();
+ ord_tuples_.accelerate(tmp_marking);
+ } else {
+ accelerate(p_curr_node_, tmp_marking);
+ }
+ ++computation_stats_.nb_accelerated;
+
// NOTE: In this implementation, a new node is created only when
// reaching the following line. Note that this differs from what is
// described in the reference paper (see the documentation of
diff git a/src/mincoversetcomputer.hpp b/src/mincoversetcomputer.hpp
index 5b800bb..a43c6dc 100644
 a/src/mincoversetcomputer.hpp
+++ b/src/mincoversetcomputer.hpp
@@ 256,13 +256,16 @@ private:
* \ref article "[Reynier]". The implementation differs from the
* algorithm in the article in two places:
* * The acceleration of the new omegamarking (cf. line 7 of algorithm
 * 2 in \ref article "[Reynier]") is done inplace in this
 * implementation, which can lead to some overacceleration compared
 * to the acceleration function described in the section 3.1 of
 * \ref article "[Reynier]". This doesn't affect the validity of
 * the algorithm which still converges to the right solution. It can
 * only in the best case reduce the number of iterations needed to
 * reach the solution compared to the version in the paper.
+ * 2 in \ref article "[Reynier]") is only performed after
+ * checking the domination condition (cf. line 9 of algorithm 2 in
+ * \ref article "[Reynier]"). Furthermore, the acceleration of the
+ * new omegamarking is done inplace in this implementation, which
+ * can lead to some overacceleration compared to the acceleration
+ * function described in the section 3.1 of \ref article "[Reynier]".
+ * This doesn't affect the validity of the algorithm which still
+ * converges to the right solution. It can only in the best case
+ * reduce the number of iterations needed to reach the solution
+ * compared to the version in the paper.
* * In the paper, a new node *n* is created and added to the set of
* nodes for each acceleration (cf. lines 7 and 8 of algorithm 2 in
* \ref article "[Reynier]"), but in the case where the condition
diff git a/tests/tests_main.cpp b/tests/tests_main.cpp
index a9171cd..b57a470 100644
 a/tests/tests_main.cpp
+++ b/tests/tests_main.cpp
@@ 224,7 +224,7 @@ TEST_CASE("parse_args_and_compute()", "[main]") {
std::string expected_stats_bfs =
"Nb wait: 11\n"
 "Nb accelerated: 10\n"
+ "Nb accelerated: 8\n"
"Nb nodes: 9\n"
"Nb min. cover. set: 6\n";
@@ 243,7 +243,7 @@ TEST_CASE("parse_args_and_compute()", "[main]") {
std::string expected_stats_dfs =
"Nb wait: 15\n"
 "Nb accelerated: 15\n"
+ "Nb accelerated: 12\n"
"Nb nodes: 13\n"
"Nb min. cover. set: 6\n";

GitLab