【问题标题】:Boost Graph find neighbours of a group of verticesBoost Graph 查找一组顶点的邻居
【发布时间】:2019-10-20 22:31:54
【问题描述】:

我有一个undirected_unweighted_graph graph;,其定义如下:

typedef typename boost::adjacency_list<boost::vecS,boost::vecS,boost::undirectedS,boost::no_property,boost::no_property> undirected_unweighted_graph;

它有几个由无向边相互连接的顶点。 在我的算法中,我正在搜索graph 的连通子图,它只包含一些具有某些属性的顶点。

我正在使用一个线性优化软件包,它为我的问题提供了可能的最佳解决方案。解决方案由一组具有固定大小 n 的顶点组成,并且可能是不可行的(即顶点在graph 的相应子图中未连接)。我目前正在使用解决方案的顶点生成一个新图,并添加也存在于graph 中的边。我正在使用boost::connected_components() 来计算它的连通分量。

现在我来回答我的问题:
对我来说,下一步是通过施加约束来提高生成解决方案的性能。具体来说,我将“发展”一个解决方案,从单个节点开始,以n 节点的子图结束。在每个阶段,部分解决方案将通过添加其中一个邻居来增长。 (这个想法是,如果部分解决方案可以发展为完整解决方案,那么它的至少一个邻居将在完整解决方案中。)我如何识别这些邻居?

我的方法如下:

我正在迭代每个组件,然后迭代 boost::out_edges(v, g)。然后我必须检查邻居是否是我的组件的一部分。如果它不是组件的一部分,我将其添加到组件邻居组中。我想知道是否有任何方法可以提升迭代boost::out_edges(V, g) 以获得顶点列表V

编辑

更具体地说:给定一个图,我可以像这样迭代给定顶点的邻居:

for (auto edge: boost::make_iterator_range(boost::out_edges(v, graph))) {
    //do stuff
}

如果我有一个连通分量,比如说一个顶点向量std::vector&lt;size_t&gt; component。我想要的是组件的出边,这意味着顶点的所有出边,不包括在component 的两个顶点之间的那些。有没有一种优雅的方法可以有效地获得这些优势?

【问题讨论】:

  • FWIW,你的问题有点宽泛。考虑将您的问题限制得更具体。
  • 我没有注意到这一点。我更新了我的问题。
  • 我很困惑 “如果某个子图是解决方案的一部分,那么至少它的一个邻居也必须是解决方案的一部分。” 这似乎是不可能的,除非您的意思是“正确的子图”并且解决方案包含所有顶点。 为什么:解决方案由一组顶点组成。这些顶点形成一个子图,因此该子图的至少一个邻居(不在子图中,因此不在解决方案中)必须是解决方案的一部分?邻居既不在解中,又在解中——矛盾。
  • 一个解有一个固定的大小 n。此语句仅适用于具有
  • @michip96 抱歉,我没有注意到您的回复,因为您没有在回复中标记我。我仍然不明白你在做什么。您会得到一个大小为n 的解决方案,您可以使用它来基于原始图形生成一个新图形。要检测“不可行”,请使用 boost::connected_components() 确保新图已连接(即具有单个连接组件)。下一步是获取解决方案的适当子图,并确保它有一个邻居是解决方案的一部分?但是只有一个连接的组件可以保证这一点,那么为什么要进行这个测试呢?

标签: c++ boost graph


【解决方案1】:

我不会迭代多个顶点。相反,我会维护两组顶点——一组包含当前部分解决方案中的顶点,另一组包含与部分解决方案相邻(而不是在)部分解决方案中的顶点。当线性优化包将顶点添加到部分解中时,该顶点也应该从邻接集移动到解中的顶点集。接下来需要迭代来自新顶点的边,但只有来自新顶点的边。对于与新顶点相邻的每个顶点,如果它不在部分解中,则将其添加到相邻顶点集合中。

我也会尝试类似的事情,只使用一组包含部分解决方案中的顶点和与部分解决方案相邻的顶点。更少的开销。根据周围的代码所期望的,这个集合可能和只有相邻顶点的集合一样有效。

这种方法的优点是可以消除重复性工作。如果您已经查看了顶点 A 的所有邻居,为什么仅仅因为顶点 B 已添加到您的集合中,就需要再次查看它们

这种方法的一个缺点是,如果您有时需要回溯(想想深度优先搜索和维护这些集合的堆栈),您可能需要大量的内存开销。这有多糟糕取决于n 有多大,以及平均有多少条边连接到每个顶点。即使在一个糟糕的情况下,一些巧妙的冗余消除可能会挽救这种方法,但我会留到以后。

【讨论】:

  • 感谢您的回答。遗憾的是,线性优化程序需要大量内存(即它迅速超过 64GB 的 RAM)。此外,我无法通过该过程“跟踪”解决方案。因此,我需要一种方法来有效地收集给定组件的最大大小子集的邻居(如果存在)。无论如何,这肯定适用于我以外的其他应用程序。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-07-30
  • 1970-01-01
  • 2020-01-29
  • 1970-01-01
相关资源
最近更新 更多