4

The following code throws "negative edge weight" on prim_minimum_spanning_treecall even though i am using only positive numbers. What should be changed to make it work?

typedef boost::property<vertex_distance_t, int> VertexProperty;
typedef boost::property<edge_weight_t, int> EdgeProperty;
typedef adjacency_list<vecS, vecS, undirectedS, VertexProperty, EdgeProperty> Graph;

typedef pair<int, int> Edge;

Edge edges[] =      {Edge(0, 1), Edge(1, 2)};
int weights[] =     {2, 1}; // this works: int weights[] =   {1, 2}; 

Graph g(edges, edges + sizeof(edges)/sizeof(Edge), weights, 3);
std::vector<Graph::vertex_descriptor> predecessors(num_vertices(g));
boost::prim_minimum_spanning_tree(g, &predecessors[0]);

Note: I can make it succeed by tweaking weight values.

Compiler : MS Visual Studio 2010 C++ Boost version: 1.54

alexm
  • 6,854
  • 20
  • 24
  • It doesn't seem like they would be, but perhaps the weights are cumulative, so any descent in weight would mean an edge had negative weight? Obvious test: does it always succeed if the weights are ascending, and always fail if they're descending values? – Jerry Coffin Aug 17 '13 at 17:12
  • @Jerry Coffin: Yes, it is sensitive to the ordering. Since the above code works correctly with boost ver 1.53 I tend to beleive it is a bug in the latest boost version (1.54). – alexm Aug 17 '13 at 21:03
  • @alexm I see that you have already [reported the bug](https://svn.boost.org/trac/boost/ticket/9012), and it has been fixed (incredibly fast!). – llonesmiz Aug 18 '13 at 09:09

1 Answers1

0

This was a Boost bug, and is already fixed: if anyone else sees this behavior from 1.54, just update to 1.55 or newer.

LThode
  • 1,843
  • 1
  • 17
  • 28