【问题标题】:boost graph library: deterministic order of iteration of in_edges?提升图库:in_e​​dges 的确定性迭代顺序?
【发布时间】:2015-09-07 05:45:27
【问题描述】:

TL;DR:我非常希望in_edges 的迭代顺序 在我的图表上(adjacency_list with edge_list of setS)是 确定性,但据我所知,迭代的顺序是 由只是指针的比较运算符确定 比较---因此迭代顺序由 malloc。救命!

具体来说,我的图表和相关类型是:

struct VertexCargo { int Id; ... };

typedef adjacency_list<setS, vecS, bidirectionalS, property<vertex_info_t, VertexCargo> > Graph;

typedef graph_traits<Graph>::edge_descriptor   ED;
typedef graph_traits<Graph>::vertex_descriptor VD;

我的逻辑,以防有人在任何地方发现谬误:

  1. in_edges迭代直接由边列表容器的迭代决定

  2. setS 的边列表暗示底层容器std::set&lt;edge_desc_impl&gt; 注意:这个假设是不正确的;它实际上是一个std::set&lt;StoredEdge,它提供了一个比较边缘目标的比较器。

  3. std::set&lt;edge_desc_impl&gt; 迭代顺序由 operator&lt;(edge_desc_impl, edge_desc_impl)

  4. operator&lt;(edge_desc_impl, edge_desc_impl) 最终只是一个 指针比较;

运算符boost/graph/detail/edge.hpp (boost 1.58):

30      template <typename Directed, typename Vertex>
31      class edge_desc_impl  : public edge_base<Directed,Vertex> {

...

35        typedef void                              property_type;
36
37        inline edge_desc_impl() : m_eproperty(0) {}
38
39        inline edge_desc_impl(Vertex s, Vertex d, const property_type* eplug)
40          : Base(s,d), m_eproperty(const_cast<property_type*>(eplug)) { }
41
42        property_type* get_property() { return m_eproperty; }
43        const property_type* get_property() const { return m_eproperty; }
44
45        //  protected:
46        property_type* m_eproperty;
47      };
48

...

63
64      // Order edges according to the address of their property object
65      template <class D, class V>
66      inline bool
67      operator<(const detail::edge_desc_impl<D,V>& a,
68                 const detail::edge_desc_impl<D,V>& b)
69      {
70        return a.get_property() < b.get_property();
71      }

如果有办法进行比较,我真的很喜欢 (因此迭代顺序)基于确定性的东西 (即 not 由 mallloc 确定的指针地址;例如 我编写的自定义运算符查看VertexCargo::Id 的源代码和 边缘的目标),但看起来这在这里可能不可行 因为void* 演员表。

从上面的代码来看,注入property 也是可能的(?) 给出所需的顺序。但这让我觉得是个黑客。

谁有智慧可以分享?


答案说明

@sehe 的回答是正确答案——底层容器实际上是一个std::set&lt;StoredEdge&gt;,它定义了一个在边缘目标上进行比较的operator&lt;;当顶点容器选择器为vecS 时,此是确定性的但不是一般情况(因为在其他情况下,顶点标识符基本上是从 malloc 获得的指针)。

【问题讨论】:

  • 目标是什么。只是按顺序迭代,还是按顺序底层存储? (IOW 您希望这是一种优化,还是代码清晰度问题)
  • 我的目标是有序迭代;如果没有必要实现这一点,我不需要按顺序存储。但我希望不必转储到向量然后手动排序,如果这就是你得到的......
  • 我预计这会比看起来更容易,而且确实如此。一些假设的类型不太好。看我的回答:)

标签: c++ boost boost-graph


【解决方案1】:

正如我所期望的(根据我的回忆),边缘列表(输入/输出)已经按其目标排序,因此它们是确定性的。

当 VertexContainer 选择器为 vecS 时,这一点尤其明确,因为 vertex_descriptor 是一个简单的整数类型,无论如何它都兼作您的 vertex_index_t 属性。

兔子洞

因为我不是 Boost Graph 开发人员,因此我不知道 BGL 类型的架构,例如adjacency_list,我天真地从我们的 顶级入口点:

template <class Config>
inline std::pair<typename Config::in_edge_iterator,
                 typename Config::in_edge_iterator>
in_edges(typename Config::vertex_descriptor u,
         const bidirectional_graph_helper<Config>& g_)
{
  typedef typename Config::graph_type graph_type;
  const graph_type& cg = static_cast<const graph_type&>(g_);
  graph_type& g = const_cast<graph_type&>(cg);
  typedef typename Config::in_edge_iterator in_edge_iterator;
  return
    std::make_pair(in_edge_iterator(in_edge_list(g, u).begin(), u),
                   in_edge_iterator(in_edge_list(g, u).end(), u));
}

实例化为:

std::pair<typename Config::in_edge_iterator, typename Config::in_edge_iterator>
boost::in_edges(typename Config::vertex_descriptor, const boost::bidirectional_graph_helper<C> &)

与

Config = boost::detail::adj_list_gen<
    boost::adjacency_list<boost::setS, boost::vecS, boost::bidirectionalS, VertexCargo>, boost::vecS, boost::setS,
    boost::bidirectionalS, VertexCargo, boost::no_property, boost::no_property, boost::listS>::config;

typename Config::in_edge_iterator = boost::detail::in_edge_iter<
    std::_Rb_tree_const_iterator<boost::detail::stored_edge_iter<
        long unsigned int, std::_List_iterator<boost::list_edge<long unsigned int, boost::no_property> >,
        boost::no_property> >,
    long unsigned int, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, long int>;

 typename Config::vertex_descriptor = long unsigned int

填写

using Config = boost::detail::adj_list_gen<
     boost::adjacency_list<boost::setS, boost::vecS, boost::bidirectionalS, VertexCargo>, boost::vecS, boost::setS,
     boost::bidirectionalS, VertexCargo, boost::no_property, boost::no_property, boost::listS>::config;

将实例化指向adj_list_gen&lt;...&gt;::config,然后将迭代器声明为

typedef in_edge_iter<
    InEdgeIter, vertex_descriptor, edge_descriptor, InEdgeIterDiff
> in_edge_iterator;

// leading to
typedef OutEdgeIter InEdgeIter;

// leading to
typedef typename OutEdgeList::iterator OutEdgeIter;

// leading to
typedef typename container_gen<OutEdgeListS, StoredEdge>::type OutEdgeList;

因为容器选择器是setS,所以会是StoredEdge的std::set,也就是

typedef typename mpl::if_<on_edge_storage,
    stored_edge_property<vertex_descriptor, EdgeProperty>,
    typename mpl::if_<is_edge_ra,
    stored_ra_edge_iter<vertex_descriptor, EdgeContainer, EdgeProperty>,
    stored_edge_iter<vertex_descriptor, EdgeIter, EdgeProperty>
    >::type
>::type StoredEdge;

计算结果为

boost::detail::stored_edge_iter<
    long unsigned int,
    std::_List_iterator<boost::list_edge<long unsigned int, boost::no_property> >,
    boost::no_property>

现在这当然指向 EdgeList 的实现...

现在坚持!踩刹车

但最重要的是施加的总体弱排序 - 所以我们不去 再往下那个兔子洞,而是把我们的注意力转移到 stored_edge_iter&lt;&gt;::operator&lt; 或类似的。

  inline bool operator<(const stored_edge& x) const
    { return m_target < x.get_target(); }

啊哈!排序已经确定性定义。您可以使用例如直接访问它

for (auto v : make_iterator_range(vertices(g))) {
    std::cout << v <<  " --> ";

    auto const& iel = boost::in_edge_list(g, v);
    for (auto e : iel) std::cout << e.get_target() << " ";
    std::cout << "\n";
}

但你不需要。使用通用图形访问器几乎相同:

std::cout << v <<  " --> ";
for (auto e : make_iterator_range(in_edges(v, g)))  std::cout << source(e, g) << " ";
std::cout << "\n";

您可以使用例如验证集合是否按预期正确排序

assert(boost::is_sorted(make_iterator_range(in_edges(v,g))  | transformed(sourcer(g))));
assert(boost::is_sorted(make_iterator_range(out_edges(v,g)) | transformed(targeter(g))));

演示

这是一个完整的演示,包括以上所有内容,并在一个大型随机生成的图表上断言所有预期的顺序:

Live On Coliru

#include <iostream>
#include <boost/graph/adjacency_list.hpp>
#include <boost/graph/properties.hpp>
#include <boost/graph/random.hpp>
#include <boost/graph/graph_utility.hpp>
#include <random>

#include <boost/range/adaptors.hpp>
#include <boost/range/algorithm.hpp>
#include <boost/range/algorithm_ext.hpp>

using boost::adaptors::transformed;
using namespace boost;

struct VertexCargo { int Id = rand() % 1024; };

typedef adjacency_list<setS, vecS, bidirectionalS, VertexCargo> Graph;

typedef graph_traits<Graph>::edge_descriptor   ED;
typedef graph_traits<Graph>::vertex_descriptor VD;

struct sourcer {
    using result_type = VD;

    Graph const* g;
    sourcer(Graph const& g) : g(&g) {}
    VD operator()(ED e) const { return boost::source(e, *g); }
};

struct targeter {
    using result_type = VD;

    Graph const* g;
    targeter(Graph const& g) : g(&g) {}
    VD operator()(ED e) const { return boost::target(e, *g); }
};

int main() {

    std::mt19937 rng { std::random_device{}() };

    Graph g;
    generate_random_graph(g, 1ul<<10, 1ul<<13, rng);

    for (auto v : make_iterator_range(vertices(g))) {
        std::cout << v <<  " --> ";

        //auto const& iel = boost::in_edge_list(g, v);
        //for (auto e : iel) std::cout << e.get_target() << " ";

        for (auto e : make_iterator_range(in_edges(v, g)))  std::cout << source(e, g) << " ";
        //for (auto e : make_iterator_range(out_edges(v, g))) std::cout << target(e, g) << " ";

        std::cout << "\n";

        assert(boost::is_sorted(make_iterator_range(in_edges(v,g))  | transformed(sourcer(g))));
        assert(boost::is_sorted(make_iterator_range(out_edges(v,g)) | transformed(targeter(g))));
    }
}

【讨论】:

  • 感谢您进入兔子洞!您是使用 IDE 帮助还是只是阅读所有源代码?我必须承认,我发现 boost 源有点令人生畏,而且在某些情况下,它打败了我的 IDE。 i关于您的回答:这似乎是正确的---仍在阅读代码...---但实际上,由于这种顺序关系只是部分顺序,in_edges 可能对于收敛于一个共同点的边缘的顺序仍然是不确定的目标。
  • 呃。 std::set 根据定义不包含具有等效顺序的元素,因此您的问题不存在 :)
  • 顺便说一句,我使用了 gcc + vim + YouCompleMe。我首先将std::cerr&lt;&lt;__PRETTY_FUNCTION__&lt;&lt; "\n"; 植入in_edges() 以获得重载+推导类型。然后主要是看源码,operator&lt;是在the value of foo here上使用YcmCompleter GoToDeclaration定位的。是的,提升对我来说也令人生畏。有时感觉非常必要。哦,好吧:)
  • 啊,是的,您对std::set 的看法是正确的,当然……每个等价类只包含一个条目……无论如何,我对边缘存储方式的心理模型是不正确的,因此我的这里的混乱。感谢您提请我注意stored_edge。比较是明确的。让我看看我现在的问题在哪里......
  • 嗨@sehe,感谢您的帮助,我想我已经确定了问题所在。事实上,在我的代码库中,我的向量列表选择器是listS 而不是vecS,在这种情况下,您确定的比较取决于内存中的地址。坦率地说,我有点惊讶这是这样的;也许 BGL 实施者在 vertex_index 上进行比较会更正确?
猜你喜欢
  • 1970-01-01
  • 2013-01-27
  • 2011-06-02
  • 1970-01-01
  • 2012-02-16
  • 1970-01-01
  • 2019-10-18
  • 2012-09-17
  • 1970-01-01
相关资源
最近更新 更多