This commit changes the relax function that dijkstra shortest paths uses to only update the distance and predecessor map of the target vertex of each edge. This has the benefit that from now on we can use std::plus as the default combine function.
<boost/graph/named_function_params.hpp>
* Original fix worked only when one boost::parameter::keyword was bound and passed in. This fix now works when binding and passing in one or more boost::parameter::keyword objects.
<boost/graph/isomorphism.hpp>
* Make isomorphism_impl a metafunction that returns the function object result_type for the fix to work.
"test/isomorphism.cpp"
* Test the fix with two boost::parameter::keyword objects.
".travis.yml"
"appveyor.yml"
* Update as per Peter Dimov's message announcing the merging of CMake into boostorg/develop.
<boost/graph/named_function_params.hpp>
* Revert unnecessary changes.
"test/Jamfile.v2"
* Add alias statements to deal with xcode compile failures stemming from Boost.Filesystem.
* Mark regressions as expected.
"travis.yml"
* Remove xcode6.4 from test suite since Travis Cl deprecated it.
* Add xcode9.4.1 to test suite.
<boost/pending/bucket_sorter.hpp>
* Work around OSX implementation of iterator copy constructor defined in private scope.
<boost/graph/named_function_params.hpp>
* Use typename add_const<remove_reference<typename T::value_type>::type>::type vice const typename T::value_type within boost::parameter::aux::tagged_argument type definition.
* Use boost::mpl::has_key vice boost::detail::parameter_exists.
* Add missing boost::graph::[function_name] overload defintion that takes in ArgumentPack as the last parameter.
"example/Jamfile.v2"
* Define BOOST_PARAMETER_EXPONENTIAL_OVERLOAD_THRESHOLD_ARITY=0 where applicable to suppress generation of exponential boost::parameter::parameters::operator() overloads and prevent ICE failures.
"test/Jamfile.v2"
* Define BOOST_PARAMETER_EXPONENTIAL_OVERLOAD_THRESHOLD_ARITY=0 where applicable to suppress generation of exponential boost::parameter::parameters::operator() overloads and prevent ICE failures.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
Replace them by their cousins from std::allocator_traits. Without that, heaps of deprecation warnings will fall onto humble users when compiling with MSVC 15 in C++17 mode.
Signed-off-by: Daniela Engert <dani@ngrt.de>
Boost's iterator.hpp is deprecated, too. Therefore get rid of all of that and replace inheritance by lifting std::iterator's members into the derived class.
Signed-off-by: Daniela Engert <dani@ngrt.de>
In C++17 mode, libc++'s `std::shuffle` isn't compatible with Boost's random
generators because the `min` and `max` functions aren't `constexpr`, so use
`std::mt19937` instead. This might not be required if boostorg/random#24 is
accepted.
csr_out_edge_iterator and csr_in_edge_iterator are part of the
boost::detail namespace, so they need to explicitly qualify
iterator_core_access in their friend declarations. Note that
csr_edge_iterator already gets this correct.
Works fine with c++11, thanks!
System: (K)Ubuntu 16.04 LTS
Compiler: g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Try to 'g++ -c' the four SGB examples girth.cpp, miles_span.cpp,
roget_components.cpp, and topo-sort-with-sgb.cpp.
(1) SGB 2002-01-30 changed the 'Associated Press scores' from 'ap0' and
'ap1' to 'ap'. This preprocessor macro (sic!) collides with numerous
function parameters in 'named_function_params.hpp'. '#undef'ining the
macro doesn't break the BGL examples.
(2) girth.cpp fails because of a missing 'null_vertex()' function.
(3) roget_components.cpp invokes 'strncmp()' from the C library.
(4) topo-sort-with-sgb.cpp hickups because of a missing 'vertices()'
function. Following roget_components.cpp and putting the collective
SGB header up front fixes this.
* Add travis-ci as CI for boostorg/graph repo.
I thought it would be a great idea to have the test running from a
"neutral entity" instead of having to checkout the pull request and
cd libs/graph/test && ../../../b2
I saw that many other boostorg submodules had their own CI system:
- compute relies on travis-ci
- geometry uses circleci
The major difference between circleci and travis-ci is the multi-threading supported by circleci. Both are free for open-source project (as of 2016/04/26). I chose travis-ci because I know how to configure it.
As for geometry, we could also use coveralls.io to display the test covering reports and improve the quality/coverage of tests on boostorg/graph.
IMPORTANT: a member of boostorg will have to add the repo boostorg/graph into travis-ci for it to work.
* csr_graph_test won't pass unless -std=c++11 is enabled
* Fixed gcc too old (4.6.3) using instead gcc-4.8 for -std=c++11
So we can at least make the examples use a more consistent code style.
Run clang-format like so:
$ clang-format -i *.cpp
and use git diff to see what has changed.
This will strip trailing whitespace too. You can ignore that by
using git diff -w
* examples: Sort the examples in the Jamfile.
This makes it easier to see which example files are even
mentioned in the build.
* examples: Build all examples.
To at least test that they build with the current API.
The newly-mentioned files here seem to be mostly (maybe all) the
BGL book examples that were added in 2001:
https://github.com/boostorg/graph/commit/5215e9b4f201bf4509a78abe89d16cb8f4199bbd
I would prefer to put these all in an examples/bgl_book subdirectory.
* Examples build: Comment out examples that cannot be expected to build.
For instance, because they depend on SBG or Stanford Graph.
* Examples: Add missing <iostream> includes.
* Examples: Comment out unused typedefs and variables.
* Examples: king_ordering: Adapt to newer API.
Specify the extra parameter for king_ordering().
The API was changed in 2005:
https://github.com/boostorg/graph/commit/4bc19a162166c025ba878cf77e959deab8cf1983
The test code was already correct:
https://github.com/imvu/boost/blob/master/libs/graph/test/king_ordering.cpp
* Examples: Some graphviz examples: Link to the library.
read_graphviz() is not header only.
* csr-example: Pass edge_are_sorted to constructor.
To use the new (well, in 2009) API:
https://github.com/boostorg/graph/commit/809904f268eb719e400fb20a4b62e17c45247066
* iteration_macros: Use BGL_FORALL_ADJ.
Not BGL_FORALL_ADJACENT(), which doesn't exist, because this was
changed in 2001:
https://github.com/boostorg/graph/commit/a0061ba07e8662561b362461c2d4347a5eb5f236
* examples: kevin-bacon2: Fix the build.
Include boost/serialization/string.hpp to fix this error:
kevin-bacon2.cpp:68:9: required from here
../../../boost/serialization/access.hpp:116:9: error: ‘class std::__cxx11::basic_string<char>’ has no member named ‘serialize’
and link to the boost serialization library.
* examples: loop_dfs: Add a missing typename keyword.
* examples: accum-compile-times: Remove unused variables.
* Examples: Remove unused typedefs.
* examples: avoid warning about parentheses aronud &&.
* example: read_graphviz: Actually use status.
* Example: adj_list_ra_edgelist: Fix the build.
The [] syntax must have worked once but doesn't anymore.
This fixes the build but it is even more clearl now a stupid way to use
the edge iterator.
* Examples: Remove unused typedefs.
* Examples: Remove an unused variable.
* Example: iohb: A const correction.
Otherwise newer compilers complain about converting string literals
to char* when callig this function.
* Exmaples: iohb: Avoid security warning with fprintf().
* Examples: Actually use a variable.
* Examples: Comment out all Graphviz examples.
These use the now-non-existant GraphizGraph and GraphvizDigraph
types. Presumably these could be updated but it's not obvious how
to do that:
https://svn.boost.org/trac/boost/ticket/4762
* Add travis-ci as CI for boostorg/graph repo.
I thought it would be a great idea to have the test running from a
"neutral entity" instead of having to checkout the pull request and
cd libs/graph/test && ../../../b2
I saw that many other boostorg submodules had their own CI system:
- compute relies on travis-ci
- geometry uses circleci
The major difference between circleci and travis-ci is the multi-threading supported by circleci. Both are free for open-source project (as of 2016/04/26). I chose travis-ci because I know how to configure it.
As for geometry, we could also use coveralls.io to display the test covering reports and improve the quality/coverage of tests on boostorg/graph.
IMPORTANT: a member of boostorg will have to add the repo boostorg/graph into travis-ci for it to work.
* csr_graph_test won't pass unless -std=c++11 is enabled
* Fixed gcc too old (4.6.3) using instead gcc-4.8 for -std=c++11
So we can at least make the examples use a more consistent code style.
Run clang-format like so:
$ clang-format -i *.cpp
and use git diff to see what has changed.
This will strip trailing whitespace too. You can ignore that by
using git diff -w
* examples: Sort the examples in the Jamfile.
This makes it easier to see which example files are even
mentioned in the build.
* examples: Build all examples.
To at least test that they build with the current API.
The newly-mentioned files here seem to be mostly (maybe all) the
BGL book examples that were added in 2001:
https://github.com/boostorg/graph/commit/5215e9b4f201bf4509a78abe89d16cb8f4199bbd
I would prefer to put these all in an examples/bgl_book subdirectory.
* Examples build: Comment out examples that cannot be expected to build.
For instance, because they depend on SBG or Stanford Graph.
* Examples: Add missing <iostream> includes.
* Examples: Comment out unused typedefs and variables.
* Examples: king_ordering: Adapt to newer API.
Specify the extra parameter for king_ordering().
The API was changed in 2005:
https://github.com/boostorg/graph/commit/4bc19a162166c025ba878cf77e959deab8cf1983
The test code was already correct:
https://github.com/imvu/boost/blob/master/libs/graph/test/king_ordering.cpp
* Examples: Some graphviz examples: Link to the library.
read_graphviz() is not header only.
* csr-example: Pass edge_are_sorted to constructor.
To use the new (well, in 2009) API:
https://github.com/boostorg/graph/commit/809904f268eb719e400fb20a4b62e17c45247066
* iteration_macros: Use BGL_FORALL_ADJ.
Not BGL_FORALL_ADJACENT(), which doesn't exist, because this was
changed in 2001:
https://github.com/boostorg/graph/commit/a0061ba07e8662561b362461c2d4347a5eb5f236
* examples: kevin-bacon2: Fix the build.
Include boost/serialization/string.hpp to fix this error:
kevin-bacon2.cpp:68:9: required from here
../../../boost/serialization/access.hpp:116:9: error: ‘class std::__cxx11::basic_string<char>’ has no member named ‘serialize’
and link to the boost serialization library.
* examples: loop_dfs: Add a missing typename keyword.
* examples: accum-compile-times: Remove unused variables.
* Examples: Remove unused typedefs.
* examples: avoid warning about parentheses aronud &&.
* example: read_graphviz: Actually use status.
* Example: adj_list_ra_edgelist: Fix the build.
The [] syntax must have worked once but doesn't anymore.
This fixes the build but it is even more clearl now a stupid way to use
the edge iterator.
* Examples: Remove unused typedefs.
* Examples: Remove an unused variable.
* Example: iohb: A const correction.
Otherwise newer compilers complain about converting string literals
to char* when callig this function.
* Exmaples: iohb: Avoid security warning with fprintf().
* Examples: Actually use a variable.
* Examples: Comment out all Graphviz examples.
These use the now-non-existant GraphizGraph and GraphvizDigraph
types. Presumably these could be updated but it's not obvious how
to do that:
https://svn.boost.org/trac/boost/ticket/4762
So people can see what the project even is when they reach the GitHub repository.
Also, even the documentation doesn't have an actual short description of what
BGL is.
And, without a direct link, it is very hard to find the list of open issues
on Boost's trac system.
With many improvements from Maël Valais:
https://github.com/murraycu/graph/pull/1
* trac 11374: find_flow_cost() not working with bundled properties.
When using bundled for Weight and Cost properties, find_flow_cost() coudln't work because the properties had been "hard coded" instead of using generic types.
Fixes https://svn.boost.org/trac/boost/ticket/11374
* trac 12038: max-flow algorithms not working with named parameters.
The named parameter "Capacity" was not working. I just had to reverse the order of get_param_type parameters.
Here are the max-flow algorithms that are curretly not working with the named parameter "Capacity":
- edmonds_karp_max_flow,
- push_relabel_max_flow,
- boykov_kolmogorov_max_flow.
Fixes https://svn.boost.org/trac/boost/ticket/12038
* trac 11374: find_flow_cost() not working with named parameters and bundled properties at the same time.
When using bundled properties as well as named parameters, there was an error.
What happened is that the "named parameters" version of find_flow_cost() was not using a generic return value, hence the error.
Also, the return value_type was using edge_capacity_value instead of edge_weight_value (which is the type of a flow cost).
I fixed it using the trick used for edmonds_karp_max_flow(): add `edge_weight_value` to named_function_params.hpp.
* Unit test find_flow_cost() with bundled properties & named params.
-> unit tests for trac 11374
I used the existing min_cost_max_flow_utils.hpp, but I had to make the graph of getSampleGraph() more generic.
In the first place, I wanted to make a compile-only test but I also made
the test runnable so we check that
- find_flow_cost works() correctly with bundled properties
- successive_shortest_path_nonnegative_weights() also works with bundled properties
To run this test, this is a bit painful...
I had to run the entire graph-related tests.
- I commented the other tests except for graph in ./status/Jamfile.v2
- in this same dir, I ran `../b2`
One issue though: csr_graph_test seems to be broken on my boost copy, I may have an issue with updating the submodules or something...
* Unit test edmond_karp_max_flow with named params & bundled properties.
-> unit tests for trac 12038
As the previous commit, I rely on min_cost_max_flow_utils.hpp.
And I also made a runnable test instead of a simple "compile-time" test.
* Indented with 2 spaces instead of tabs
Thanks for the patch!
Pass the indexMap parameter through to the dominator_visitor and use it
instead of get(vertex_index, g). This allows this algorithm to be used
for graphs without a vertex_index property.
Addresses bug #11742.
This appears to be fixed, we may have to patch this to ensure there's no backward compatibility issues with older compilers. Thanks for the bug report and patch.
The bug that it never gets called with the current construction remains.
The C++ standard deprecates use of <stdio.h>, <stdlib.h> etc., and suggests using <cstdio>, <cstdlib> etc.
Some trailing whitespace removed in affected files because of a setting in my editor
dead code surrounded by #if 0 ... #endif removed
* Fix labeled_graph constructors
* Wraparound bug leads to out-of-bounds addressing.
Seems obvious that `> 0` was meant (seeing the comments).
Also, if `vertices_size_type` is unsigned - which it usually (always?) is - the loop condition was never false.
* Finally, one constructor didn't properly initialize the graph property
* Copy vertex property on add_vertex
Tested with clang on El Capitan, thanks!
* Fix documentation about type alias edge_size_type -> edges_size_type
This replaces occurences of `edge_size_type` (sg.) in the documentation
with the actual `edges_size_type` (pl.) as it is named in the
implementation.
There is a graph implementation (Stanford graph) that has a type alias
of `edge_size_type` (sg.) --- I did not change that implementation, as
it would break backwards compatibility, and therefore I also did not
change its documentation.
* Fix documentation on push_relabel algorithm, defined in header: preflow_push -> push_relabel
This test demonstrates incorrect output in
the order edges are finished. We're using
this test to both ensure finish_edge is
called, and that the output is incorrect.
Once we fix where the visitor is called,
this test will be changed to check for the
correct output.
If compiler doesn't support has_member_function for member
templates, use old TTI syntax to avoid compiler error.
Supported compilers are gcc 4.9 and newer, clang any platform,
and intel 12 and newer.
Changed the usage of TTI so that finish_edge is actually
called when defined. Also regularized the finish_edge
signature so E is passed by value and G by const ref.
So people can see what the project even is when they reach the GitHub repository.
Also, even the documentation doesn't have an actual short description of what
BGL is.
And, without a direct link, it is very hard to find the list of open issues
on Boost's trac system.
With many improvements from Maël Valais:
https://github.com/murraycu/graph/pull/1
array_binary_tree_node::children_type::iterator pretends to be a bidirectional iterator but does not define operator--, which results in compile breaks with Visual C++ 2015.
* trac 11374: find_flow_cost() not working with bundled properties.
When using bundled for Weight and Cost properties, find_flow_cost() coudln't work because the properties had been "hard coded" instead of using generic types.
Fixes https://svn.boost.org/trac/boost/ticket/11374
* trac 12038: max-flow algorithms not working with named parameters.
The named parameter "Capacity" was not working. I just had to reverse the order of get_param_type parameters.
Here are the max-flow algorithms that are curretly not working with the named parameter "Capacity":
- edmonds_karp_max_flow,
- push_relabel_max_flow,
- boykov_kolmogorov_max_flow.
Fixes https://svn.boost.org/trac/boost/ticket/12038
* trac 11374: find_flow_cost() not working with named parameters and bundled properties at the same time.
When using bundled properties as well as named parameters, there was an error.
What happened is that the "named parameters" version of find_flow_cost() was not using a generic return value, hence the error.
Also, the return value_type was using edge_capacity_value instead of edge_weight_value (which is the type of a flow cost).
I fixed it using the trick used for edmonds_karp_max_flow(): add `edge_weight_value` to named_function_params.hpp.
* Unit test find_flow_cost() with bundled properties & named params.
-> unit tests for trac 11374
I used the existing min_cost_max_flow_utils.hpp, but I had to make the graph of getSampleGraph() more generic.
In the first place, I wanted to make a compile-only test but I also made
the test runnable so we check that
- find_flow_cost works() correctly with bundled properties
- successive_shortest_path_nonnegative_weights() also works with bundled properties
To run this test, this is a bit painful...
I had to run the entire graph-related tests.
- I commented the other tests except for graph in ./status/Jamfile.v2
- in this same dir, I ran `../b2`
One issue though: csr_graph_test seems to be broken on my boost copy, I may have an issue with updating the submodules or something...
* Unit test edmond_karp_max_flow with named params & bundled properties.
-> unit tests for trac 12038
As the previous commit, I rely on min_cost_max_flow_utils.hpp.
And I also made a runnable test instead of a simple "compile-time" test.
* Indented with 2 spaces instead of tabs
Thanks for the patch!
Pass the indexMap parameter through to the dominator_visitor and use it
instead of get(vertex_index, g). This allows this algorithm to be used
for graphs without a vertex_index property.
Addresses bug #11742.
This appears to be fixed, we may have to patch this to ensure there's no backward compatibility issues with older compilers. Thanks for the bug report and patch.
The bug that it never gets called with the current construction remains.
The C++ standard deprecates use of <stdio.h>, <stdlib.h> etc., and suggests using <cstdio>, <cstdlib> etc.
Some trailing whitespace removed in affected files because of a setting in my editor
dead code surrounded by #if 0 ... #endif removed
* Fix labeled_graph constructors
* Wraparound bug leads to out-of-bounds addressing.
Seems obvious that `> 0` was meant (seeing the comments).
Also, if `vertices_size_type` is unsigned - which it usually (always?) is - the loop condition was never false.
* Finally, one constructor didn't properly initialize the graph property
* Copy vertex property on add_vertex
Tested with clang on El Capitan, thanks!
* Fix documentation about type alias edge_size_type -> edges_size_type
This replaces occurences of `edge_size_type` (sg.) in the documentation
with the actual `edges_size_type` (pl.) as it is named in the
implementation.
There is a graph implementation (Stanford graph) that has a type alias
of `edge_size_type` (sg.) --- I did not change that implementation, as
it would break backwards compatibility, and therefore I also did not
change its documentation.
* Fix documentation on push_relabel algorithm, defined in header: preflow_push -> push_relabel
array_binary_tree_node::children_type::iterator pretends to be a bidirectional iterator but does not define operator--, which results in compile breaks with Visual C++ 2015.
This test demonstrates incorrect output in
the order edges are finished. We're using
this test to both ensure finish_edge is
called, and that the output is incorrect.
Once we fix where the visitor is called,
this test will be changed to check for the
correct output.
If compiler doesn't support has_member_function for member
templates, use old TTI syntax to avoid compiler error.
Supported compilers are gcc 4.9 and newer, clang any platform,
and intel 12 and newer.
Changed the usage of TTI so that finish_edge is actually
called when defined. Also regularized the finish_edge
signature so E is passed by value and G by const ref.
Added graph property support to read_graphml
Well, it turns out there's already Boost.Test dependencies in Graph that I wasn't aware of. Tested with Clang 6.0 on Darwin.
Add constructor and assignment operator implementations for gcc 4.4 since it does not support defaulted move constructors and assignment. The operators are also used for gcc 4.5 for good measure (I cannot test it but gcc 4.6 does not need this workaround).
Also the workaround is used for MSVC as well. The previous MSVC branch was incorrect since it did not invoke base class constructors and assignment.
On Linux, GNU's libstdc++, which is the default stdlib for icc and clang,
cannot parse the <iomanip> header in version 4.5+ (which thankfully neither
compiler advises the use of yet), as it's original C++98-friendly
implementation has been replaced with a gnu++0x implementation.
<boost/detail/iomanip.hpp> is a portable implementation of <iomanip>, providing
boost::detail::setfill, boost::detail::setbase, boost::detail::setw,
boost::detail::setprecision, boost::detail::setiosflags and
boost::detail::resetiosflags.
[SVN r68140]
The initial checkin supports bundled properties for adjacency list,
matrix, undirected and directed graphs, the labeled graph adaptor
and the reverse graph adaptor. All tests updated, passed.
Documentation should be updated, but isn't yet.
[SVN r64645]
At the request of the authors of the published algorithm, the header
and all associated functions, data types, tests, examples, and docs
should be renamed to boykov_kolmogorov. Branched all of the necessary
documents and renamed all such functions and data types.
Added deprecation warnings to the kolmogorov_max_flow.hpp and to the
kolmogorov_max_flow.html.
[SVN r63189]
Mostly to use the images and css files under doc/src instead of
doc/html, usually be deleting the settings in order to use the defaults.
Also add 'boost.root' to some builds in order to fix links which rely on
it.
[SVN r63146]
This avoids pulling in any more names than necessary for maximum backward compatibility.
Also the old algorithms that are not duplicated have been reinstated again to maximize backward compatibility.
[SVN r61049]
which seems to be where most basic data structures. The change introduces
no name collisions, since its only user is mutable_queue. This change
deprecates the use of adstl::array_binary_tree for all users.
[SVN r60611]
A generic interface for traversing graphs, using C++ templates.
The full documentation is available on [boost.org](http://www.boost.org/doc/libs/release/libs/graph/doc/index.html).
## Support, bugs and feature requests ##
Bugs and feature requests can be reported through the [Trac issue tracker](https://svn.boost.org/trac/boost/query?component=graph&desc=1&order=id)
(see [open issues](https://svn.boost.org/trac/boost/query?status=!closed&component=graph&desc=1&order=id) and
[closed issues](https://svn.boost.org/trac/boost/query?status=closed&component=graph&col=id&col=summary&col=status&col=owner&col=type&col=milestone&col=version&desc=1&order=id)). [Here](http://lists.boost.org/Archives/boost/2015/04/221780.php) is why Trac is still in use.
You can submit your changes through a [pull request](https://github.com/boostorg/graph/pulls). One of the maintainers will take a look (remember that it can take some time).
There is no mailing-list specific to Boost Graph, although you can use the general-purpose Boost [mailing-list](http://lists.boost.org/mailman/listinfo.cgi/boost-users) using the tag [graph].
## Development ##
Clone the whole boost project, which includes the individual Boost projects as submodules ([see boost+git doc](https://github.com/boostorg/boost/wiki/Getting-Started)):
git clone https://github.com/boostorg/boost
cd boost
git submodule update --init
The Boost Graph Library is located in `libs/graph/`.
Boost Graph Library is mostly made of headers but also contains some compiled components. Here are the build commands:
./bootstrap.sh <- compile b2
./b2 headers <- just installs headers
./b2 <- build compiled components
**Note:** The Boost Graph Library cannot currently be built outside of Boost itself.
### Running tests ###
First, make sure you are in `libs/graph/test`.
You can either run all the 300+ tests listed in `Jamfile.v2` or run a single test:
../../../b2 <- run all tests
../../../b2 cycle_canceling_test <- single test
You can also check the [regression tests reports](http://beta.boost.org/development/tests/develop/developer/graph.html).
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<p>An <i>UpdatableQueue</i> is a refinement of the <ahref="./Buffer.html">Buffer</a> concept that additionally requires that the Buffer be updatable.
<p>Implicit in the definition is an ordering of values. Though access to the order is not required, types that model UpdatableQueue must document how an object of the type orders values so that a program may change the position of a given value in the ordering. For example, an UpdatableQueue may choose to order values by using a property map, and a value <tt>v1</tt> is considered less than a value <tt>v2</tt> if <tt><nobr>get(pm, v1) < get(pm, v2)</nobr></tt>. A program can update the properties of values, thus changing the order of values in the UpdatableQueue, and notify the UpdatableQueue of the specific values that have a different position in the ordering by calling the <tt>update</tt> member of the UpdatableQueue on each.
<p>A program that modifies the order must notify the UpdatableQueue of values that may have different positions in the ordering since they were inserted or last updated.
<h3>Notation</h3>
<table>
<tr><td><tt>Q</tt></td><td> is a type that models UpdatableQueue. </td></tr>
<tr><td><tt>T</tt></td><td> is the value type of <tt>Q</tt>. </td></tr>
</table>
<h3>Members</h3>
For a type to model the UpdatableQueue concept it must have the following members
in addition to the members that are required of types that model <ahref="./Buffer.html">Buffer</a>:
<p>An <i>UpdatablePriorityQueue</i> is a slight refinement of <ahref="#concept%3AUpdatableQueue">UpdatableQueue</a>
that imposes the requirement that a program may not increase the position of a value that is held in the queue. That is,
if a value <tt>v</tt> had position <i>n</i> in the ordering, a program may update the position of <tt>v</tt> only to 0, 1, ..., <i>n</i> - 1, or <i>n</i>, where 0 is the top of the queue.
<p>The behavior when a program attempts to increase a value's position in the ordering is undefined.
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
template <class <ahref="./EdgeListGraph.html">EdgeListGraph</a>, class Size, class WeightMap,
class PredecessorMap, class DistanceMap,
class <ahref="http://www.sgi.com/tech/stl/BinaryFunction.html">BinaryFunction</a>, class <ahref="http://www.sgi.com/tech/stl/BinaryPredicate.html">BinaryPredicate</a>,
class <ahref="http://www.boost.org/sgi/stl/BinaryFunction.html">BinaryFunction</a>, class <ahref="http://www.boost.org/sgi/stl/BinaryPredicate.html">BinaryPredicate</a>,
class <ahref="./BellmanFordVisitor.html">BellmanFordVisitor</a>>
bool bellman_ford_shortest_paths(EdgeListGraph& g, Size N,
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/doug_gregor.html">Doug Gregor</A>, Indiana University (<scriptlanguage="Javascript">address("cs.indiana.edu","dgregor")</script>)<br>
Jeremiah Willcock, Indiana University (<scriptlanguage="Javascript">address("osl.iu.edu","jewillco")</script>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
@@ -413,7 +419,7 @@ The time complexity is <i>O(V log V)</i>.
is invoked on vertex <i>v</i> when the edge
<i>(u,v)</i> is examined and <i>v</i> is WHITE. Since
a vertex is colored GRAY when it is discovered,
each reacable vertex is discovered exactly once. This
each reachable vertex is discovered exactly once. This
is also when the vertex is inserted into the priority queue.
<li><b><tt>vis.edge_not_relaxed(e, g)</tt></b>
is invoked if the edge is not relaxed (see above).
@@ -429,7 +435,7 @@ See <a href="../example/dijkstra-example.cpp">
<TT>example/dijkstra-example.cpp</TT></a> for an example of using Dijkstra's
algorithm.
<H3>See also</H3><ahref="dijkstra_shortest_paths_no_color_map.html">dijkstra_shortest_paths_no_color_map</a> for a version of dijkstra's shortest path that does not use a color map.
<H3>See also</H3><ahref="dijkstra_shortest_paths_no_color_map.html">dijkstra_shortest_paths_no_color_map</a> for a version of Dijkstra's shortest path that does not use a color map.
@@ -69,7 +69,7 @@ Algorithms</A> for some background to the shortest-path problem.
</P>
<P>
<tt>dijkstra_shortest_paths_no_color_map</tt> differs from the original <tt>dijkstra_shortest_paths</tt> algorithm by not using a color map to identify vertices as discovered or undiscovered. Instead, this is done with the distance map: a vertex <i>u</i> such that <i>distance_compare(distance_map[u], distance_infinity) == false</i> is considered to be undiscovered.
<tt>dijkstra_shortest_paths_no_color_map</tt> differs from the original <tt>dijkstra_shortest_paths</tt> algorithm by not using a color map to identify vertices as discovered or undiscovered. Instead, this is done with the distance map: a vertex <i>u</i> such that <i>distance_compare(distance_map[u], distance_infinity) == false</i> is considered to be undiscovered. Note that this means that edges with infinite weight will not work correctly in this algorithm.
</P>
<P>
@@ -116,10 +116,6 @@ indicated by the labels on the right.
<tdvalign="top">
<pre>
DIJKSTRA(<i>G</i>, <i>s</i>, <i>w</i>)
<b>for</b> each vertex <i>u in V</i><b>(This loop is not run in dijkstra_shortest_paths_no_color_map_no_init)</b>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
The <tt>directed_graph</tt> class template is a simplified version
of the BGL adjacency list. This class is provided for ease of use, but
may not perform as well as custom-defined adjacency list classes. Instances
of this template model the BidirectionalGraph, VertexIndexGraph, and
EdgeIndexGraph concepts.
<H3>Example</H3>
A simple examples of creating a directed_graph is available here <ahref="../../../libs/graph/example/directed_graph.cpp"><tt>libs/graph/example/directed_graph.cpp</tt></a>.
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/doug_gregor.html">Doug Gregor</A>, Indiana University (<scriptlanguage="Javascript">address("cs.indiana.edu","dgregor")</script>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
<p>Given an undirected graph <i>G</i> = (<i>V</i>, <i>E</i>), a <em>cut</em> of <i>G</i> is a partition of the vertices into two, non-empty sets <i>X</i> and <imgsrc="stoer_wagner_imgs/6e4.gif"alt="\overline{X} = V - X"style="vertical-align: middle; padding-bottom: 2px">. The <i>weight</i> of a cut is defined as the number of edges between sets <i>X</i> and <imgsrc="stoer_wagner_imgs/f79.gif"alt="\overline{X}"style="vertical-align: middle; padding-bottom: 3px"> if <i>G</i> is unweighted, or the sum of the weights of all edges between sets <i>X</i> and <imgsrc="stoer_wagner_imgs/f79.gif"alt="\overline{X}"style="vertical-align: middle; padding-bottom: 3px"> if <i>G</i> is weighted (each edge has an associated, non-negative weight).
<p>When the weight of a cut <imgsrc="stoer_wagner_imgs/8b7.gif"alt="C = \{X, \overline{X}\}"style="vertical-align: middle"> is minimal for a graph <i>G</i> (that is, no other cut of <i>G</i> has a lesser weight), then the cut is known as a <em>minimum cut</em> or a <em>min-cut</em>. For example, given this weighted graph:
<p>Unlike this example, a graph will sometimes have multiple min-cuts, all of equal weight. A minimum cut algorithm determines one of them as well as the min-cut weight.
<h3>Directed Graphs</h3>
<p>Given a directed graph <i>G</i> = (<i>V</i>, <i>E</i>), a <em>cut</em> of <i>G</i> is a partition of the vertices into two, non-empty sets <i>S</i> and <i>T</i> where <i>S</i> is known as the set of <em>source vertices</em> and <i>T</i> is known as the set of <em>sink vertices</em>. The <em>capacity</em> of a cut <i>C</i> = (<i>S</i>, <i>T</i>) is the number of edges from a vertex in <i>S</i> to a vertex in <i>T</i> if <i>G</i> is unweighted, or the sum of weights of edges from a vertex in <i>S</i> to a vertex in <i>T</i> if <i>G</i> is weighted.
<p>When the capacity of a cut <i>C</i> = (<i>S</i>, <i>T</i>) of a directed graph is minimal (that is, no other cut of <i>G</i> has lesser capacity), then <i>C</i> is known as a <em>minimum cut</em> or <em>min-cut</em>.
<AHREF="http://www.boost.org/people/liequan_lee.htm">Lie-Quan Lee</A>, Indiana University (<AHREF="mailto:llee@cs.indiana.edu">llee@cs.indiana.edu</A>)<br>
with all functions in the <tt>boost</tt> namespace. All examples are available in a single program file in<ahref="../../../libs/graph/example/grid_graph_example.cpp"><tt>libs/graph/example/grid_graph_example.cpp</tt></a>
with all functions in the <tt>boost</tt> namespace. A simple examples of creating and iterating over a grid_graph is available here <ahref="../../../libs/graph/example/grid_graph_example.cpp"><tt>libs/graph/example/grid_graph_example.cpp</tt></a>. An example of adding properties to a grid_graph is also available<ahref="../../../libs/graph/example/grid_graph_example.cpp"><tt>libs/graph/example/grid_graph_properties.cpp</tt></a>
</p>
<h4>Template Parameters</h4>
@@ -81,13 +81,13 @@
</pre>
<ul>
<li>
<tt>Dimensions</tt> - Number of dimensions in the graph, <b>must be greater than 2</b>
<tt>Dimensions</tt> - Number of dimensions in the graph
</li>
<li>
<tt>VertexIndex</tt> - Type used for vertex indices, defaults to std::size_t
<tt>VertexIndex</tt> - Type used for vertex indices, defaults to <tt>std::size_t</tt>
</li>
<li>
<tt>EdgeIndex</tt> - Type used for edge indices, defaults to the same type as VertexIndex
<tt>EdgeIndex</tt> - Type used for edge indices, defaults to the same type as <tt>VertexIndex</tt>
</li>
</ul>
@@ -111,7 +111,7 @@
<h4>Example</h4>
<preclass="code">
<spanclass="comment">// Define dimension lengths, a 3x3 in this case</span>
Jeremiah Willcock, Indiana University (<scriptlanguage="Javascript">address("osl.iu.edu","jewillco")</script>)<br>
<AHREF="http://www.boost.org/people/doug_gregor.html">Doug Gregor</A>, Indiana University (<scriptlanguage="Javascript">address("cs.indiana.edu","dgregor")</script>)<br>
Indiana University (<scriptlanguage="Javascript">address("osl.iu.edu","lums")</script>)
</TD></TR></TABLE>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
jzmaddock
