Boost图形库:确定in_edges的迭代顺序?

6
TL;DR: 我希望在我的图 (adjacency_list,边列表为 setS) 上进行的 in_edges 迭代顺序是确定性的,但据我所知,迭代顺序由指针比较决定,因此迭代顺序受到 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<StoredEdge>,它提供了一个比较器,按照边缘目标进行比较。 注意:这个假设是错误的;实际上它是一个std::set<StoredEdge, 它提供了一个比较器,按照边缘目标进行比较。

  3. std::set<edge_desc_impl> 的迭代顺序由operator<(edge_desc_impl, edge_desc_impl) 决定

  4. operator<(edge_desc_impl, edge_desc_impl) 最终成为一个 指针比较

operator<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      }

我希望有一种方式能够诱导比较(从而迭代顺序)基于某些确定性的因素(即不是由mallloc确定的指针地址;例如,我编写的自定义运算符查看源和目标边的VertexCargo::Id),但由于void*转换,看起来在这里可能行不通。

从上面的代码中也可以看出,注入一个给定的排序属性似乎也是可能的(?)。但那听起来像是一个hack

有人有智慧分享吗?


答案说明

@sehe的回答是正确的答案---底层容器实际上是一个std::set<StoredEdge>,它定义了一个比较运算符operator<,该运算符根据边目标进行比较;当顶点容器选择器为vecS时,这是确定性的,但一般情况下并不是(因为其他情况下顶点标识符基本上是从malloc得到的指针)。


目标是什么?只是按顺序迭代,还是按顺序底层存储?(也就是说,您希望这是一种优化,还是代码清晰性的问题) - sehe
我的目标是按顺序迭代;如果不需要这样做,我不需要按顺序存储。但是,我希望不必转储到向量中,然后手动排序,如果你是这个意思的话... - David Alexander
我本以为这会比看起来容易些,而事实确实如此。一些假定的类型并不完全正确。请查看我的答案 :) - sehe
1个回答

7

正如我所预料的那样(根据我的回忆),边缘列表(无论是入边还是出边)已经按照它们的目标有序排列,因此它们是确定性的

当选择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> &)

with

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<...>::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,因此它将是一个StoredEdgestd::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<>::operator<或类似操作。
  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))));

演示

这是一个完整的演示,包括所有内容,并对大型随机生成的图表进行了所有预期排序的断言:

在 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。关于你的回答:它似乎是正确的 --- 我仍在阅读代码... --- 但实际上,由于此顺序关系仅是部分顺序,in_edges可能仍然不确定涉及汇聚到共同目标的边缘的顺序。 - David Alexander
嗯,“std::set” 的定义不包含具有等价顺序的元素,因此您的问题不存在 :) - sehe
1
顺便说一下,我使用的是gcc + vim + YouCompleteMe. 我开始在 in_edges() 中插入了 std :: cerr << __PRETTY_FUNCTION__<< "\n"; 以获得重载和推导类型。然后主要是阅读源代码,使用 YcmCompleter GoToDeclaration 定位到了 operator<,可以在这里的foo值上找到它。是的,boost对我来说也是令人生畏的。有时候感觉超过了必要性。嗯,好吧 :) - sehe
啊,是的,你关于std::set的说法是正确的,当然...它只包含每个等价类的一个条目...无论如何,我对边缘存储方式的心理模型是错误的,因此在这里感到困惑。感谢你提醒我注意stored_edge。比较是明确的。让我看看现在我的问题在哪里... - David Alexander
嗨@sehe,感谢您的帮助,我认为我已经找到了问题所在。实际上,在我的代码库中,我的向量列表选择器是listS而不是vecS,在这种情况下,您所识别的比较取决于内存地址。坦白地说,我有点惊讶,也许BGL实现者应该比较vertex_index才更正确? - David Alexander
显示剩余2条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接