[PBGL] Betweenness centrality and named vertexes
Hello, I'm trying to use `brandes_betweenness_centrality` with named vertexes but so far I haven't managed to get it working. These are the two approaches I tried: 1. passing an iterator_property_map on the vertex_index: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph.cp... 2. passing a property_map on a float inside the vertex: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2.c... And these are the compile logs for the first file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang.log gcc:https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc.log and the second file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang2.log gcc: https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc2.log What I'm doing wrong? Thanks in advance
Hi, unfortunately, I can't help you directly with that one as I have no MPI installed. I compared your code to one of my attempts to work with brandes_betweenness_centrality and I could not find anything that would make me say "Change this, and it should work". However, the documentation of brandes_betweenness_centrality says for the centrality_map: The value type of this property map should be a floating-point or rational type. I don't know if you already tried that out. When I eliminate the MPI-parts and simply define adjacency_list <vecS, vecS, bidirectionalS, Vertex>, it compiles just fine. Also the vector<int> seems not to be a problem, although it might be for your results later on. What is interesting me though is, why you define an internal_vertex_name, when you already have it as a bundled property? Best, Cedric On Saturday, 27. November 2010 11:07:05 Carmine Paolino wrote:
Hello,
I'm trying to use `brandes_betweenness_centrality` with named vertexes but so far I haven't managed to get it working.
These are the two approaches I tried:
1. passing an iterator_property_map on the vertex_index: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph. cpp
2. passing a property_map on a float inside the vertex: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2 .cpp
And these are the compile logs for the first file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang.log gcc:https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc.log
and the second file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang2.log gcc: https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc2.log
What I'm doing wrong?
Thanks in advance _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 27 Nov 2010, at 11:50, Cedric Laczny wrote:
Hi,
unfortunately, I can't help you directly with that one as I have no MPI installed. I compared your code to one of my attempts to work with brandes_betweenness_centrality and I could not find anything that would make me say "Change this, and it should work". However, the documentation of brandes_betweenness_centrality says for the centrality_map: The value type of this property map should be a floating-point or rational type. I don't know if you already tried that out.
Yes, it's in the second example: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2.c...
When I eliminate the MPI-parts and simply define adjacency_list <vecS, vecS, bidirectionalS, Vertex>, it compiles just fine. Also the vector<int> seems not to be a problem, although it might be for your results later on.
What is interesting me though is, why you define an internal_vertex_name, when you already have it as a bundled property?
Those two files are just examples to reproduce the problem we have in the actual code. `internal_vertex_name` is independent from bundled properties: you can use it either with bundled properties or with a Vertex or Edge structure and it allows us to find a vertex by name and to automatically add it if that vertex isn't already in the graph. See the docs here: http://www.boost.org/doc/libs/release/libs/graph_parallel/doc/html/distribut... The Vertex structure, by the way, give us more flexibility than the bundled properties and also results in more maintainable code. Carmine Paolino
Best,
Cedric
On Saturday, 27. November 2010 11:07:05 Carmine Paolino wrote:
Hello,
I'm trying to use `brandes_betweenness_centrality` with named vertexes but so far I haven't managed to get it working.
These are the two approaches I tried:
1. passing an iterator_property_map on the vertex_index: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph. cpp
2. passing a property_map on a float inside the vertex: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2 .cpp
And these are the compile logs for the first file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang.log gcc:https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc.log
and the second file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang2.log gcc: https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc2.log
What I'm doing wrong?
Thanks in advance _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Saturday, 27. November 2010 12:19:47 Carmine Paolino wrote:
On 27 Nov 2010, at 11:50, Cedric Laczny wrote:
Hi,
unfortunately, I can't help you directly with that one as I have no MPI installed. I compared your code to one of my attempts to work with brandes_betweenness_centrality and I could not find anything that would make me say "Change this, and it should work". However, the documentation of brandes_betweenness_centrality says for the centrality_map: The value type of this property map should be a floating-point or rational type. I don't know if you already tried that out.
Yes, it's in the second example: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2 .cpp
When I eliminate the MPI-parts and simply define adjacency_list <vecS, vecS, bidirectionalS, Vertex>, it compiles just fine. Also the vector<int> seems not to be a problem, although it might be for your results later on.
What is interesting me though is, why you define an internal_vertex_name, when you already have it as a bundled property?
Those two files are just examples to reproduce the problem we have in the actual code. `internal_vertex_name` is independent from bundled properties: you can use it either with bundled properties or with a Vertex or Edge structure and it allows us to find a vertex by name and to automatically add it if that vertex isn't already in the graph. See the docs here: http://www.boost.org/doc/libs/release/libs/graph_parallel/doc/html/distrib uted_adjacency_list.html#named-vertices
Thank you very much for that information.
The Vertex structure, by the way, give us more flexibility than the bundled properties and also results in more maintainable code.
This is not intended to be picky. I simply want to clarify this for me. Because AFAIK, using "external" classes or structs to represent properties of vertices or edges is the concept of bundled properties (just as you do in the examples). Using e.g. vertex_index_t or such (e.g. as defined in properties.hpp) follows the concept of internal properties?! Nevertheless, I agree with you absolutely that using structs or classes to represent the properties is far more flexible and increases the maintainability of the code. Best, Cedric
Carmine Paolino
Best,
Cedric
On Saturday, 27. November 2010 11:07:05 Carmine Paolino wrote:
Hello,
I'm trying to use `brandes_betweenness_centrality` with named vertexes but so far I haven't managed to get it working.
These are the two approaches I tried:
1. passing an iterator_property_map on the vertex_index: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_grap h. cpp
2. passing a property_map on a float inside the vertex: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_grap h2 .cpp
And these are the compile logs for the first file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang.log gcc:https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc.log
and the second file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang2.log gcc: https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc2.log
What I'm doing wrong?
Thanks in advance _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 27 Nov 2010, at 12:48, Cedric Laczny wrote:
Thank you very much for that information.
You're welcome. :)
This is not intended to be picky. I simply want to clarify this for me. Because AFAIK, using "external" classes or structs to represent properties of vertices or edges is the concept of bundled properties (just as you do in the examples). Using e.g. vertex_index_t or such (e.g. as defined in properties.hpp) follows the concept of internal properties?! Nevertheless, I agree with you absolutely that using structs or classes to represent the properties is far more flexible and increases the maintainability of the code.
Oh, I'm so sorry… I mis[understood/named] bundled for internals, and structs for bundled… My fault; we agree.
I read a little about PBGL and even though I still don't know any solution to you problem, it might help to bring in some ideas? If I understood the documentation correctly, the vertices are distributed over the available processes by some distribution. Except for using the named vertices solution, it is only possible to access the vertices local to the process (simply via indices). Digging a little into the headers, I found that the function local(), that the compiler is complaining about, must be implemented by the "templated" BaseDistribution (boost/graph/distributed/shuffled_distribution.hpp). So I could think of that the object of the class BaseDistribution does not implement this local()- function. When looking at the example adjacency_list<>-definition of the documentation on PBGL, I see they are using mpi::bsp_process_group whereas you are using mpi_process_group. I don't know if that makes a difference, but when I look at http://www.osl.iu.edu/research/pbgl/documentation/mpi_bsp_process_group.html, I can see no definition of local() there... And it seems that this local() function performs the access of the vertex local to the process via indices. My thoughts on this are that either there is a bug and that the local() function needs to be implemented accordingly or that there is something going wrong with using named-vertices here. It might be worth a try to leave that aside and compile your example without that code. Or you could test if your code compiles when using a different algorithm than brandes_betwenness_centrality, e.g. breadth_first_search() or such (if they have distributed specializations for them) Other possibilites might very well exist and might be more appropriate so I am looking forward to hear those. For the moment these were the ideas that came to my mind. Best, Cedric On Saturday, 27. November 2010 11:07:05 Carmine Paolino wrote:
Hello,
I'm trying to use `brandes_betweenness_centrality` with named vertexes but so far I haven't managed to get it working.
These are the two approaches I tried:
1. passing an iterator_property_map on the vertex_index: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph. cpp
2. passing a property_map on a float inside the vertex: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2 .cpp
And these are the compile logs for the first file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang.log gcc:https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc.log
and the second file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang2.log gcc: https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc2.log
What I'm doing wrong?
Thanks in advance _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
A response to all your emails follow: On 27 Nov 2010, at 14:11, Cedric Laczny wrote:
I read a little about PBGL and even though I still don't know any solution to you problem, it might help to bring in some ideas? If I understood the documentation correctly, the vertices are distributed over the available processes by some distribution. Except for using the named vertices solution, it is only possible to access the vertices local to the process (simply via indices). Digging a little into the headers, I found that the function local(), that the compiler is complaining about, must be implemented by the "templated" BaseDistribution (boost/graph/distributed/shuffled_distribution.hpp). So I could think of that the object of the class BaseDistribution does not implement this local()-function.
In fact it does not. BaseDistribution is a hashed_distribution when using a named graph, defined in boost/graph/distributed/named_graph.hpp Great insight, I'm taking a closer look at this.
When looking at the example adjacency_list<>-definition of the documentation on PBGL, I see they are using mpi::bsp_process_group whereas you are using mpi_process_group. I don't know if that makes a difference, but when I look at http://www.osl.iu.edu/research/pbgl/documentation/mpi_bsp_process_group.html, I can see no definition of local() there...
I don't know the origin of bsp_process_group, in fact I tried to compile with this instead of mpi_process_group and it doesn't work… Probably it's old: deprecated in the code, but left in the documentation…
And it seems that this local() function performs the access of the vertex local to the process via indices. My thoughts on this are that either there is a bug and that the local() function needs to be implemented accordingly or that there is something going wrong with using named-vertices here. It might be worth a try to leave that aside and compile your example without that code.
Yes, without this declaration it does compile: template<> struct internal_vertex_name<Vertex> { typedef multi_index::member<Vertex, std::string, &Vertex::name> type; }; But the comfort of having boost manage adding and finding vertexes also goes away, which means we have to use something like a map of all the inserted names on a single process to know if a name should be added to the graph or not. And that doesn't scale well. Anyway I'm open to suggestion on this if the named graph way doesn't work…
Or you could test if your code compiles when using a different algorithm than brandes_betwenness_centrality, e.g. breadth_first_search() or such (if they have distributed specializations for them)
The code compiles and runs well with degree centrality, node strength (a generalization of degree centrality to graphs with weighted edges), and PageRank. You can see the working code here: https://github.com/earcar/lana
Other possibilites might very well exist and might be more appropriate so I am looking forward to hear those. For the moment these were the ideas that came to my mind.
Thanks! ---
I found out that you are not alone with that problem. Please see http://stackoverflow.com/q/4258136
Actually, he is working with me on this issue :)
Maybe it was fixed in a recent version of the Boost library?
I have 1.45 on my computer, and have a FreeBSD build server with 1.43 but it doesn't work in both cases. ---
Hi,
sorry, to split the whole communication into such "small" pieces. Your problem really puzzles me and I can hardly quit trying to understand what is causing it.
No problem, you're welcome!
I would really be interested in the result when leaving the named vertices aside.
See above.
AFAIK this should not be necessary to see if your distributed code will compile, even with brandes_betweenness_centrality(). You might ask why this plays a role. Actually, when I look at your error logs, I see " /usr/local/include/boost/graph/distributed/shuffled_distribution.hpp: In member function ‘size_t boost::graph::distributed::shuffled_distribution<BaseDistribution>::operator() (const T&) const [with T = size_t, BaseDistribution = boost::graph::distributed::hashed_distribution<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]’: The problem here is the collision between size_t and char* (std::basic_string). The argument should be of type size_t (index of a vertex for the local process) but the underlying distribution is based on std::basic_string, probably due to the named vertices (specialization in named_graph.hpp). This causes an error at line 40 of boost/graph/distributed/named_graph.hpp which is called by line 68 in boost/graph/distributed/shuffled_distribution.hpp. So the specialization to named vertices could be the cause.
While this might not resolve the issue with local(), it could actually track down one error and might reveal a bug.
Yes, I think you got it right. And thanks for the clear explanation. :) I'm now exploring the possibilities I have: if I can implement the local() function or if there's something else I can do. Thanks, Carmine
On Saturday, 27. November 2010 16:03:19 Carmine Paolino wrote:
When looking at the example adjacency_list<>-definition of the documentation on PBGL, I see they are using mpi::bsp_process_group whereas you are using mpi_process_group. I don't know if that makes a difference, but when I look at http://www.osl.iu.edu/research/pbgl/documentation/mpi_bsp_process_group. html, I can see no definition of local() there...
I don't know the origin of bsp_process_group, in fact I tried to compile with this instead of mpi_process_group and it doesn't work… Probably it's old: deprecated in the code, but left in the documentation…
This was just a guess and as we see it seems not to affect your problem.
And it seems that this local() function performs the access of the vertex local to the process via indices. My thoughts on this are that either there is a bug and that the local() function needs to be implemented accordingly or that there is something going wrong with using named-vertices here. It might be worth a try to leave that aside and compile your example without that code.
Yes, without this declaration it does compile:
template<> struct internal_vertex_name<Vertex> { typedef multi_index::member<Vertex, std::string, &Vertex::name> type; };
But the comfort of having boost manage adding and finding vertexes also goes away, which means we have to use something like a map of all the inserted names on a single process to know if a name should be added to the graph or not. And that doesn't scale well. Anyway I'm open to suggestion on this if the named graph way doesn't work…
I agree with you on this one. I experienced the boost library to be very efficient in all cases where I used it and the authors probably have thought about this in order to make it suitable (and fast) for distributed purposes. In fact, I find this feature very convenient and I think it may be also helpful in non-distributed graphs. Using already existing features is IMHO definitively nicer than putting all kinds of maps or such on top for lookup-purposes. It will only bloat the code and make it harder to read and maintain and probably will steal preformance. That's why it is important to check if this is actually a bug :)
Or you could test if your code compiles when using a different algorithm than brandes_betwenness_centrality, e.g. breadth_first_search() or such (if they have distributed specializations for them)
The code compiles and runs well with degree centrality, node strength (a generalization of degree centrality to graphs with weighted edges), and PageRank. You can see the working code here: https://github.com/earcar/lana
Do you mean the code including the named vertices or the code without the named vertices?
Maybe it was fixed in a recent version of the Boost library?
I have 1.45 on my computer, and have a FreeBSD build server with 1.43 but it doesn't work in both cases.
While this might not resolve the issue with local(), it could actually track down one error and might reveal a bug.
Yes, I think you got it right. And thanks for the clear explanation. :)
I'm now exploring the possibilities I have: if I can implement the local() function or if there's something else I can do.
Good to see that tracking down that error seems to have worked :) Thank you for testing the suggestions. Because this might represent a bug (you seem to have the most recent version of boost - maybe except for the svn-versions) and since you are actually working on that problem, could you please file a bug report on this? Maybe it will even be fixed in the november bug sprint... General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010
Thanks,
Your are welcome
Carmine
Best, Cedric
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 27 Nov 2010, at 16:34, Cedric Laczny wrote:
On Saturday, 27. November 2010 16:03:19 Carmine Paolino wrote:
When looking at the example adjacency_list<>-definition of the documentation on PBGL, I see they are using mpi::bsp_process_group whereas you are using mpi_process_group. I don't know if that makes a difference, but when I look at http://www.osl.iu.edu/research/pbgl/documentation/mpi_bsp_process_group. html, I can see no definition of local() there...
I don't know the origin of bsp_process_group, in fact I tried to compile with this instead of mpi_process_group and it doesn't work… Probably it's old: deprecated in the code, but left in the documentation…
This was just a guess and as we see it seems not to affect your problem.
In boost/graph/parallel/process_group.hpp, comments suggest that `mpi_process_group` uses a BSP-type communication model, so I'm almost certain that that was an older name for the same function. I will also file a bug for this.
Yes, without this declaration it does compile:
template<> struct internal_vertex_name<Vertex> { typedef multi_index::member<Vertex, std::string, &Vertex::name> type; };
But the comfort of having boost manage adding and finding vertexes also goes away, which means we have to use something like a map of all the inserted names on a single process to know if a name should be added to the graph or not. And that doesn't scale well. Anyway I'm open to suggestion on this if the named graph way doesn't work…
I agree with you on this one. I experienced the boost library to be very efficient in all cases where I used it and the authors probably have thought about this in order to make it suitable (and fast) for distributed purposes. In fact, I find this feature very convenient and I think it may be also helpful in non-distributed graphs. Using already existing features is IMHO definitively nicer than putting all kinds of maps or such on top for lookup-purposes. It will only bloat the code and make it harder to read and maintain and probably will steal preformance.
Exactly.
That's why it is important to check if this is actually a bug :)
Or you could test if your code compiles when using a different algorithm than brandes_betwenness_centrality, e.g. breadth_first_search() or such (if they have distributed specializations for them)
The code compiles and runs well with degree centrality, node strength (a generalization of degree centrality to graphs with weighted edges), and PageRank. You can see the working code here: https://github.com/earcar/lana
Do you mean the code including the named vertices or the code without the named vertices?
It's the actual project (still in early stages!), which is implemented with named vertices.
Maybe it was fixed in a recent version of the Boost library?
I have 1.45 on my computer, and have a FreeBSD build server with 1.43 but it doesn't work in both cases.
While this might not resolve the issue with local(), it could actually track down one error and might reveal a bug.
Yes, I think you got it right. And thanks for the clear explanation. :)
I'm now exploring the possibilities I have: if I can implement the local() function or if there's something else I can do.
Good to see that tracking down that error seems to have worked :) Thank you for testing the suggestions.
Because this might represent a bug (you seem to have the most recent version of boost - maybe except for the svn-versions) and since you are actually working on that problem, could you please file a bug report on this?
Here it is: https://svn.boost.org/trac/boost/ticket/4899
Maybe it will even be fixed in the november bug sprint...
General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010
Great. Carmine
On Saturday, 27. November 2010 17:45:05 Carmine Paolino wrote:
The code compiles and runs well with degree centrality, node strength (a generalization of degree centrality to graphs with weighted edges), and PageRank. You can see the working code here: https://github.com/earcar/lana
Do you mean the code including the named vertices or the code without the named vertices?
It's the actual project (still in early stages!), which is implemented with named vertices.
Ok, because your algorithms are working with named vertices, it seems that brandes_betweenness_centrality() is calling a function that the others do not... As otherwise, these should also fail. At least that's what sounds logical to me :)
Because this might represent a bug (you seem to have the most recent version of boost - maybe except for the svn-versions) and since you are actually working on that problem, could you please file a bug report on this?
Here it is: https://svn.boost.org/trac/boost/ticket/4899
Maybe it will even be fixed in the november bug sprint...
General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010
Great.
Nice! However, I think you missed/forgot the point about named vertices and the hashed_distribution and the operator().
Carmine
Best, Cedric
On 27 Nov 2010, at 17:55, Cedric Laczny wrote:
Ok, because your algorithms are working with named vertices, it seems that brandes_betweenness_centrality() is calling a function that the others do not... As otherwise, these should also fail. At least that's what sounds logical to me :)
Actually at line 54 of `boost/graph/distributed/page_rank.hpp` I see a `local(v)`, so there might be a chance that `brandes_betweenness_centrality()` itself contains a bug.
Nice! However, I think you missed/forgot the point about named vertices and the hashed_distribution and the operator().
At first I thought that since it's the first line of the compile log, I could leave this info out. But yeah, I guess a bit of analysis can give the bug fixer a clearer picture. Carmine
Hi, I found out that you are not alone with that problem. Please see http://stackoverflow.com/q/4258136 Maybe it was fixed in a recent version of the Boost library? Best, Cedric On Saturday, 27. November 2010 11:07:05 Carmine Paolino wrote:
Hello,
I'm trying to use `brandes_betweenness_centrality` with named vertexes but so far I haven't managed to get it working.
These are the two approaches I tried:
1. passing an iterator_property_map on the vertex_index: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph. cpp
2. passing a property_map on a float inside the vertex: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2 .cpp
And these are the compile logs for the first file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang.log gcc:https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc.log
and the second file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang2.log gcc: https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc2.log
What I'm doing wrong?
Thanks in advance _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi, sorry, to split the whole communication into such "small" pieces. Your problem really puzzles me and I can hardly quit trying to understand what is causing it. I would really be interested in the result when leaving the named vertices aside. AFAIK this should not be necessary to see if your distributed code will compile, even with brandes_betweenness_centrality(). You might ask why this plays a role. Actually, when I look at your error logs, I see " /usr/local/include/boost/graph/distributed/shuffled_distribution.hpp: In member function ‘size_t boost::graph::distributed::shuffled_distribution<BaseDistribution>::operator() (const T&) const [with T = size_t, BaseDistribution = boost::graph::distributed::hashed_distribution<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]’: The problem here is the collision between size_t and char* (std::basic_string). The argument should be of type size_t (index of a vertex for the local process) but the underlying distribution is based on std::basic_string, probably due to the named vertices (specialization in named_graph.hpp). This causes an error at line 40 of boost/graph/distributed/named_graph.hpp which is called by line 68 in boost/graph/distributed/shuffled_distribution.hpp. So the specialization to named vertices could be the cause. While this might not resolve the issue with local(), it could actually track down one error and might reveal a bug. Looking forward to your answer. Best, Cedric On Saturday, 27. November 2010 11:07:05 Carmine Paolino wrote:
Hello,
I'm trying to use `brandes_betweenness_centrality` with named vertexes but so far I haven't managed to get it working.
These are the two approaches I tried:
1. passing an iterator_property_map on the vertex_index: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph. cpp
2. passing a property_map on a float inside the vertex: https://gist.github.com/f02f18f30f0eef146a58#file_betweenness_named_graph2 .cpp
And these are the compile logs for the first file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang.log gcc:https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc.log
and the second file: clang: https://gist.github.com/f02f18f30f0eef146a58#file_compile_clang2.log gcc: https://gist.github.com/f02f18f30f0eef146a58#file_compile_gcc2.log
What I'm doing wrong?
Thanks in advance _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Carmine Paolino -
Cedric Laczny