Boost图形库:in_edges迭代的确定性顺序? [英] boost graph library: deterministic order of iteration of in_edges?
问题描述
TL; DR :我非常希望in_edges的迭代顺序
在我的图上(adjacency_list，edge_list为setS)是
确定的，但据我所知，迭代的顺序是
由只是指针的比较运算符确定
比较-因此，迭代顺序由的变化决定
malloc.救命！
TL;DR: I would very much like for the order of iteration of in_edges
on my graph (adjacency_list with edge_list of setS) to be
determinstic, but as far as I can tell, the order of iteration is
determined by a comparison operator that is just pointer
comparison---thus iteration order is determined by the vagaries of
malloc. Help!
为具体起见，我的图形和相关类型为:
For concreteness, my graph and related types are:
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;
我的逻辑，以防万一有人在任何地方发现谬论:
My logic, in case anyone spots a fallacy anywhere:
-
in_edges迭代直接由边缘列表容器的迭代确定
in_edgesiteration is directly determined by iteration of the edge list container
边缘列表表示基础容器std::set<edge_desc_impl>
注意:此假设不正确；它实际上是std::set<StoredEdge，它提供了一个在边缘目标上进行比较的比较器.
edge list of setS implies underlying container std::set<edge_desc_impl>
Note: this assumption was incorrect; it is actually a std::set<StoredEdge, which offers a comparator that compares on edge target.
std::set<edge_desc_impl>迭代顺序由
operator<(edge_desc_impl, edge_desc_impl)
operator<(edge_desc_impl, edge_desc_impl)最终只是一个
指针比较;
operator<(edge_desc_impl, edge_desc_impl) ends up being just a
pointer comparison;
运算符<在boost/graph/detail/edge.hpp中定义(提升1.58):
The operator< is defined in 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确定的 not 指针地址；例如
我编写的自定义运算符在VertexCargo::Id中查找源和
边缘的目标)，但在这里似乎不可行
由于void*强制转换.
I would really like it if there were a way to induce the comparison
(and thus iteration order) to be based on something deterministic
(i.e. not pointer addresses determined by mallloc; for example a
custom operator I write that looks at VertexCargo::Id for source and
target of the edges) but it looks like that might not be workable here
because of the void* cast.
从上面的代码中，似乎还可以(?)插入property
给出所需的顺序.但这让我很吃惊.
From the code above it also looks possible (?) to inject a property
giving the desired ordering. But that strikes me as a hack.
有人有智慧要分享吗?
@sehe的回答是正确的答案-底层容器实际上是std::set<StoredEdge>，它定义了在边缘目标上进行比较的operator<；当顶点容器选择器为vecS 而不是一般而言时，此是确定性的(因为在其他情况下，顶点标识符基本上是从malloc获取的指针).
@sehe's response is the correct answer---the underlying container is in fact a std::set<StoredEdge>, which defines an operator< that compares on the edge target; this is deterministic when the vertex container selector is vecS but not in general (since the vertex identifiers in other cases are basically pointers gotten from malloc).
推荐答案
正如我所期望的(根据我的回忆)，边缘列表(输入/输出)已按其目标排序，因此它们是确定性的.
As I expected (from my recollection) the edge lists (both in/out) are already ordered by their targets, hence they are deterministic.
当VertexContainer选择器为vecS时，这尤其明确，因为在那里vertex_descriptor是简单的整数类型，无论如何，它还是您的vertex_index_t属性的两倍.
This is especially unambiguous when the VertexContainer selector is vecS because, there, the vertex_descriptor is a simple integral type, that doubles as your vertex_index_t property anyways.
因为我不是Boost Graph开发人员，所以我不知道
像adjacency_list这样的BGL类型的体系结构，我从天真的开始
顶级入口点:
Because I'm not a Boost Graph developer, and hence I donot know the
architecture of the BGL types like adjacency_list, I naively started at our
top-level entry point:
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<...>::config，并将迭代器声明为
Points us the instantiation at adj_list_gen<...>::config and there the iterator is declared as
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，即
And because the container selector is setS, it will be a std::set of StoredEdge, which is
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的实现...
Now this, of course, points to the implementation of the EdgeList...
但是最重要的是强加了全部弱排序-因此我们不去
再往那个兔子洞下走，而是将注意力转移到
stored_edge_iter<>::operator<或类似版本.
But what's most important is the total weak ordering imposed - so we don't go
further down that rabbit-hole, but instead shift our attention to
stored_edge_iter<>::operator< or similar.
inline bool operator<(const stored_edge& x) const
{ return m_target < x.get_target(); }
啊哈！该顺序已已确定定义.您可以使用例如直接直接访问它.
Aha! The ordering is already deterministically defined. You can access it directly using e.g.
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";
}
但是您不需要.使用通用图访问器几乎是相同的:
But you don't need to. Using the generic graph accessors would be pretty much the same:
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))));
演示
这是一个完整的演示，包括以上所有内容，并在大型随机生成的图上声明了所有预期的顺序:
DEMO
Here's a full demo including all the above and asserting all the expected orderings on a large random-generated graph:
#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))));
}
}
这篇关于Boost图形库:in_edges迭代的确定性顺序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
