From 85a07a091764c9bb66f05e98927f41583ede1619 Mon Sep 17 00:00:00 2001
From: Florent Jaillet <florent.jaillet@lis-lab.fr>
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 in-place 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 in-place 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 omega-marking (cf. line 7 of algorithm
- * 2 in \ref article "[Reynier]") is done in-place in this
- * implementation, which can lead to some over-acceleration 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 omega-marking is done in-place in this implementation, which
+ * can lead to some over-acceleration 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