diff --git a/dev/.documenter-siteinfo.json b/dev/.documenter-siteinfo.json
index 623f6bb2..a7d41c8a 100644
--- a/dev/.documenter-siteinfo.json
+++ b/dev/.documenter-siteinfo.json
@@ -1 +1 @@
-{"documenter":{"julia_version":"1.11.1","generation_timestamp":"2024-11-13T12:22:10","documenter_version":"1.8.0"}}
\ No newline at end of file
+{"documenter":{"julia_version":"1.11.1","generation_timestamp":"2024-11-21T11:17:14","documenter_version":"1.8.0"}}
\ No newline at end of file
diff --git a/dev/advanced/errorhandling/index.html b/dev/advanced/errorhandling/index.html
index 6eac9c10..09603e0b 100644
--- a/dev/advanced/errorhandling/index.html
+++ b/dev/advanced/errorhandling/index.html
@@ -1,2 +1,2 @@
-Error handling · Graphs.jl
In an ideal world, all software would work perfectly all the time. However, in the real world software encounters errors due to the outside world, bad input, bugs, or programmer error.
It is the position of this project that error conditions that happen often, typically due to bad data, should be handled with sentinel values returned to indicate the failure condition. These are used for functions such as add_edge!(g, u, v). If you try to add an edge with negative vertex numbers, or vertices that exceed the number of vertices in the graph, then you will get a return value of false.
For more severe failures such as bad arguments or failure to converge, we use exceptions. The primary distinction between Sentinel Values and Argument Errors has to do with the run time of the function being called. In a function that is expected to be a called in a tight loop such as add_edge!, we will use a sentinel value rather than an exception. This is because it is faster to do a simple if statement to handle the error than a full try/catch block. For functions that take longer to run, we use Exceptions. If you find an exception with an error message that isn't helpful for debugging, please file a bug report so that we can improve these messages.
ArgumentError: the inputs to this function are not valid
InexactError: some types are used that cannot express a computed quantity with the necessary precision
Settings
This document was generated with Documenter.jl version 1.8.0 on Wednesday 13 November 2024. Using Julia version 1.11.1.
In an ideal world, all software would work perfectly all the time. However, in the real world software encounters errors due to the outside world, bad input, bugs, or programmer error.
It is the position of this project that error conditions that happen often, typically due to bad data, should be handled with sentinel values returned to indicate the failure condition. These are used for functions such as add_edge!(g, u, v). If you try to add an edge with negative vertex numbers, or vertices that exceed the number of vertices in the graph, then you will get a return value of false.
For more severe failures such as bad arguments or failure to converge, we use exceptions. The primary distinction between Sentinel Values and Argument Errors has to do with the run time of the function being called. In a function that is expected to be a called in a tight loop such as add_edge!, we will use a sentinel value rather than an exception. This is because it is faster to do a simple if statement to handle the error than a full try/catch block. For functions that take longer to run, we use Exceptions. If you find an exception with an error message that isn't helpful for debugging, please file a bug report so that we can improve these messages.
ArgumentError: the inputs to this function are not valid
InexactError: some types are used that cannot express a computed quantity with the necessary precision
Settings
This document was generated with Documenter.jl version 1.8.0 on Thursday 21 November 2024. Using Julia version 1.11.1.
Graphs.Experimental is a module for graph algorithms that are newer or less stable. We can adopt algorithms before we finalize an interface for using them or if we feel that full support cannot be provided to the current implementation. You can expect new developments to land here before they make it into the main module. This enables the development to keep advancing without being risk-averse because of stability guarantees. You can think of this module as a 0.X semantic version space ; it is a place where you can play around with new algorithms, perspectives, and interfaces without fear of breaking critical code.
A Note To Users
Code in this module is unstable and subject to change. Do not use any code in this module in production environments without understanding the (large) risks involved. However, we welcome bug reports and issues via the normal channels..
Return all isomorphism from vertex induced subgraphs of g1 to g2. The isomorphisms are returned as an iterator of vectors of tuples, where the i-th vector is the i-th isomorphism and a tuple (u, v) in this vector means that u ∈ g1 is mapped to v ∈ g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Graphs.Experimental is a module for graph algorithms that are newer or less stable. We can adopt algorithms before we finalize an interface for using them or if we feel that full support cannot be provided to the current implementation. You can expect new developments to land here before they make it into the main module. This enables the development to keep advancing without being risk-averse because of stability guarantees. You can think of this module as a 0.X semantic version space ; it is a place where you can play around with new algorithms, perspectives, and interfaces without fear of breaking critical code.
A Note To Users
Code in this module is unstable and subject to change. Do not use any code in this module in production environments without understanding the (large) risks involved. However, we welcome bug reports and issues via the normal channels..
Return all isomorphism from vertex induced subgraphs of g1 to g2. The isomorphisms are returned as an iterator of vectors of tuples, where the i-th vector is the i-th isomorphism and a tuple (u, v) in this vector means that u ∈ g1 is mapped to v ∈ g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return all isomorphism from g1 to g2. The isomorphisms are returned as an iterator of vectors of tuples, where the i-th vector is the i-th isomorphism and a tuple (u, v) in this vector means that u ∈ g1 is mapped to v ∈ g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return all isomorphism from g1 to g2. The isomorphisms are returned as an iterator of vectors of tuples, where the i-th vector is the i-th isomorphism and a tuple (u, v) in this vector means that u ∈ g1 is mapped to v ∈ g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return all isomorphism from subgraphs of g1 to g2. The isomorphisms are returned as an iterator of vectors of tuples, where the i-th vector is the i-th isomorphism and a tuple (u, v) in this vector means that u ∈ g1 is mapped to v ∈ g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return all isomorphism from subgraphs of g1 to g2. The isomorphisms are returned as an iterator of vectors of tuples, where the i-th vector is the i-th isomorphism and a tuple (u, v) in this vector means that u ∈ g1 is mapped to v ∈ g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return the number of vertex induced subgraphs of the graph g1 that are isomorphic to g2.
Optional Arguments
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return the number of vertex induced subgraphs of the graph g1 that are isomorphic to g2.
Optional Arguments
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return the number of isomorphism from graph g1 to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return the number of isomorphism from graph g1 to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return the number of subgraphs of the graph g1 that are isomorphic to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return the number of subgraphs of the graph g1 that are isomorphic to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return true if the graph g1 contains a vertex induced subgraph that is isomorphic to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return true if the graph g1 contains a vertex induced subgraph that is isomorphic to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return true if the graph g1 contains a subgraph that is isomorphic to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Return true if the graph g1 contains a subgraph that is isomorphic to g2.
Optional Arguments
alg: The algorithm that is used to find the induced subgraph isomorphism. Can be only VF2() at the moment.
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
Iterate over all isomorphism between the graphs g1 (or subgraphs thereof) and g2. The problem that is solved depends on the value of problemtype:
IsomorphismProblem(): Only isomorphisms between the whole graph g1 and g2 are considered.
SubGraphIsomorphismProblem(): All isomorphism between subgraphs of g1 and g2 are considered.
InducedSubGraphIsomorphismProblem(): All isomorphism between vertex induced subgraphs of g1 and g2 are considered.
Upon finding an isomorphism, the function callback is called with a vector vmap as an argument. vmap is a vector where vmap[v] == u means that vertex v in g2 is mapped to vertex u in g1. If the algorithm should look for another isomorphism, then this function should return true.
Optional Arguments
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
References
Luigi P. Cordella, Pasquale Foggia, Carlo Sansone, Mario Vento “A (Sub)Graph Isomorphism Algorithm for Matching Large Graphs”
Return a vector filled with the geodesic distances of vertices in g from vertex s / unique vertices ss using BFS traversal algorithm alg. For vertices in disconnected components the default distance is typemax(T).
Iterate over all isomorphism between the graphs g1 (or subgraphs thereof) and g2. The problem that is solved depends on the value of problemtype:
IsomorphismProblem(): Only isomorphisms between the whole graph g1 and g2 are considered.
SubGraphIsomorphismProblem(): All isomorphism between subgraphs of g1 and g2 are considered.
InducedSubGraphIsomorphismProblem(): All isomorphism between vertex induced subgraphs of g1 and g2 are considered.
Upon finding an isomorphism, the function callback is called with a vector vmap as an argument. vmap is a vector where vmap[v] == u means that vertex v in g2 is mapped to vertex u in g1. If the algorithm should look for another isomorphism, then this function should return true.
Optional Arguments
vertex_relation: A binary function that takes a vertex from g1 and one from g2. An isomorphism only exists if this function returns true for all matched vertices.
edge_relation: A binary function that takes an edge from g1 and one from g2. An isomorphism only exists if this function returns true for all matched edges.
References
Luigi P. Cordella, Pasquale Foggia, Carlo Sansone, Mario Vento “A (Sub)Graph Isomorphism Algorithm for Matching Large Graphs”
Return a vector filled with the geodesic distances of vertices in g from vertex s / unique vertices ss using BFS traversal algorithm alg. For vertices in disconnected components the default distance is typemax(T).
traverse_graph!(g, s, alg, state, neighborfn=outneighbors)
traverse_graph!(g, ss, alg, state, neighborfn=outneighbors)
-Traverse a graph `g` starting at vertex `s` / vertices `ss` using algorithm `alg`, maintaining state in [`AbstractTraversalState`](@ref) `state`. Next vertices to be visited are determined by `neighborfn` (default `outneighbors`). Return `true` if traversal finished; `false` if one of the visit functions caused an early termination.
AbstractTraversalState is the abstract type used to hold mutable states for various traversal algorithms (see traverse_graph!).
When creating concrete types, you should override the following functions where relevant. These functions are listed in order of occurrence in the traversal:
Each of these functions should return a boolean. If the return value of the function is false, the traversal will return the state immediately. Otherwise, the traversal will continue.
For better performance, use the @inline directive and make your functions branch-free.
TraversalAlgorithm is the abstract type used to specify breadth-first traversal (BFS) or depth-first traversal (DFS) for the various traversal functions.
Modify AbstractTraversalStatestate on initialization of traversal with source vertices, and return true if successful; false otherwise. initfn! will be called once for each vertex passed to traverse_graph!.
Return a vector of parent vertices indexed by vertex using TraversalAlgorithmalg starting with vertex s. If neighborfn is specified, use the corresponding neighbor-generation function (inneighborsr and outneighbors are valid values).
Performance
This implementation is designed to perform well on large graphs. There are implementations which are marginally faster in practice for smaller graphs, but the performance improvements using this implementation on large graphs can be significant.
Traverse a graph g from source vertex s / vertices ss keeping track of state. Return true if traversal finished normally; false if one of the visit functions returned false (see )
Modify AbstractTraversalStatestate when the edge between u and v is encountered, and return true if successful; false otherwise. Note: visitfn! may be called multiple times per edge, depending on the traversal algorithm, for a function that operates on the first occurrence only, use newvisitfn!.
The structure used to configure and specify that shortest_paths should use the A* search algorithm. An optional heuristic function may be supplied. If missing, the heuristic is set to n -> 0.
Implementation Notes
AStar supports the following shortest-path functionality:
An optional sorting algorithm may be specified (default = no sorting). Sorting helps maintain cache locality and will improve performance on very large graphs; for normal use, sorting will incur a performance penalty.
BFS is the default algorithm used when a source is specified but no distance matrix is specified.
Implementation Notes
BFS supports the following shortest-path functionality:
The structure used to configure and specify that shortest_paths should use Dijkstra's algorithm to compute shortest paths. Optional fields for this structure include
all_paths::Bool - set to true to calculate all (redundant, equivalent) paths to a given destination
track_vertices::Bool - set to true to keep a running list of visited vertices (used for specific centrality calculations; generally not needed).
Dijkstra is the default algorithm used when a distance matrix is specified.
Implementation Notes
Dijkstra supports the following shortest-path functionality:
non-negative distance matrices / weights
(optional) multiple sources
all destinations
redundant equivalent path tracking
vertex tracking
Performance
If using a sparse matrix for distmx in shortest_paths, you may achieve better performance by passing in a transpose of its sparse transpose. That is, assuming D is the sparse distance matrix:
D = transpose(sparse(transpose(D)))
Be aware that realizing the sparse transpose of D incurs a heavy one-time penalty, so this strategy should only be used when multiple calls to shortest_paths with the distance matrix are planned.
The structure used to configure and specify that shortest_paths should use the Floyd-Warshall algorithm. No additional configuration parameters are specified or required.
FloydWarshall is the default all-pairs algorithm used when no source is specified.
Implementation Notes
FloydWarshall supports the following shortest-path functionality:
non-negative distance matrices / weights
all-pairs shortest paths
Performance
Space complexity is on the order of $\mathcal{O}(|V|^2)$.
The structure used to configure and specify that shortest_paths should use the Johnson algorithm. No additional configuration parameters are specified or required.
Implementation Notes
Johnson supports the following shortest-path functionality:
Concrete subtypes of ShortestPathAlgorithm are used to specify the type of shortest path calculation used by shortest_paths. Some concrete subtypes (most notably Dijkstra have fields that specify algorithm parameters.
Given the output of a shortest_paths calculation of type ShortestPathResult, return a vector (indexed by vertex) of the distances between the source vertex used to compute the shortest path and a single destination vertex v or the entire graph.
For ShortestPathAlgorithms that compute all-pairs shortest paths, dists(state) will return a matrix (indexed by source and destination vertices) of distances.
Given a graph g, an optional distance matrix distmx, and an optional algorithm alg (one of BellmanFord or SPFA), return true if any cycle detected in the graph has a negative weight.
Examples
julia> using Graphs, Graphs.Experimental.ShortestPaths
+Traverse a graph `g` starting at vertex `s` / vertices `ss` using algorithm `alg`, maintaining state in [`AbstractTraversalState`](@ref) `state`. Next vertices to be visited are determined by `neighborfn` (default `outneighbors`). Return `true` if traversal finished; `false` if one of the visit functions caused an early termination.
AbstractTraversalState is the abstract type used to hold mutable states for various traversal algorithms (see traverse_graph!).
When creating concrete types, you should override the following functions where relevant. These functions are listed in order of occurrence in the traversal:
Each of these functions should return a boolean. If the return value of the function is false, the traversal will return the state immediately. Otherwise, the traversal will continue.
For better performance, use the @inline directive and make your functions branch-free.
TraversalAlgorithm is the abstract type used to specify breadth-first traversal (BFS) or depth-first traversal (DFS) for the various traversal functions.
Modify AbstractTraversalStatestate on initialization of traversal with source vertices, and return true if successful; false otherwise. initfn! will be called once for each vertex passed to traverse_graph!.
Return a vector of parent vertices indexed by vertex using TraversalAlgorithmalg starting with vertex s. If neighborfn is specified, use the corresponding neighbor-generation function (inneighborsr and outneighbors are valid values).
Performance
This implementation is designed to perform well on large graphs. There are implementations which are marginally faster in practice for smaller graphs, but the performance improvements using this implementation on large graphs can be significant.
Traverse a graph g from source vertex s / vertices ss keeping track of state. Return true if traversal finished normally; false if one of the visit functions returned false (see )
Modify AbstractTraversalStatestate when the edge between u and v is encountered, and return true if successful; false otherwise. Note: visitfn! may be called multiple times per edge, depending on the traversal algorithm, for a function that operates on the first occurrence only, use newvisitfn!.
The structure used to configure and specify that shortest_paths should use the A* search algorithm. An optional heuristic function may be supplied. If missing, the heuristic is set to n -> 0.
Implementation Notes
AStar supports the following shortest-path functionality:
An optional sorting algorithm may be specified (default = no sorting). Sorting helps maintain cache locality and will improve performance on very large graphs; for normal use, sorting will incur a performance penalty.
BFS is the default algorithm used when a source is specified but no distance matrix is specified.
Implementation Notes
BFS supports the following shortest-path functionality:
The structure used to configure and specify that shortest_paths should use Dijkstra's algorithm to compute shortest paths. Optional fields for this structure include
all_paths::Bool - set to true to calculate all (redundant, equivalent) paths to a given destination
track_vertices::Bool - set to true to keep a running list of visited vertices (used for specific centrality calculations; generally not needed).
Dijkstra is the default algorithm used when a distance matrix is specified.
Implementation Notes
Dijkstra supports the following shortest-path functionality:
non-negative distance matrices / weights
(optional) multiple sources
all destinations
redundant equivalent path tracking
vertex tracking
Performance
If using a sparse matrix for distmx in shortest_paths, you may achieve better performance by passing in a transpose of its sparse transpose. That is, assuming D is the sparse distance matrix:
D = transpose(sparse(transpose(D)))
Be aware that realizing the sparse transpose of D incurs a heavy one-time penalty, so this strategy should only be used when multiple calls to shortest_paths with the distance matrix are planned.
The structure used to configure and specify that shortest_paths should use the Floyd-Warshall algorithm. No additional configuration parameters are specified or required.
FloydWarshall is the default all-pairs algorithm used when no source is specified.
Implementation Notes
FloydWarshall supports the following shortest-path functionality:
non-negative distance matrices / weights
all-pairs shortest paths
Performance
Space complexity is on the order of $\mathcal{O}(|V|^2)$.
The structure used to configure and specify that shortest_paths should use the Johnson algorithm. No additional configuration parameters are specified or required.
Implementation Notes
Johnson supports the following shortest-path functionality:
Concrete subtypes of ShortestPathAlgorithm are used to specify the type of shortest path calculation used by shortest_paths. Some concrete subtypes (most notably Dijkstra have fields that specify algorithm parameters.
Given the output of a shortest_paths calculation of type ShortestPathResult, return a vector (indexed by vertex) of the distances between the source vertex used to compute the shortest path and a single destination vertex v or the entire graph.
For ShortestPathAlgorithms that compute all-pairs shortest paths, dists(state) will return a matrix (indexed by source and destination vertices) of distances.
Given a graph g, an optional distance matrix distmx, and an optional algorithm alg (one of BellmanFord or SPFA), return true if any cycle detected in the graph has a negative weight.
Given the output of a shortest_paths calculation of type ShortestPathResult, return a vector (indexed by vertex) of the paths between the source vertex used to compute the shortest path and a single destination vertex v, a vector of destination vertices vs, or the entire graph.
For multiple destination vertices, each path is represented by a vector of vertices on the path between the source and the destination. Nonexistent paths will be indicated by an empty vector. For single destinations, the path is represented by a single vector of vertices, and will be length 0 if the path does not exist.
For ShortestPathAlgorithms that compute all shortest paths for all pairs of vertices, paths(state) will return a vector (indexed by source vertex) of vectors (indexed by destination vertex) of paths. paths(state, v) will return a vector (indexed by destination vertex) of paths from source v to all other vertices. In addition, paths(state, v, d) will return a vector representing the path from vertex v to vertex d.
Given the output of a shortest_paths calculation of type ShortestPathResult, return a vector (indexed by vertex) of the paths between the source vertex used to compute the shortest path and a single destination vertex v, a vector of destination vertices vs, or the entire graph.
For multiple destination vertices, each path is represented by a vector of vertices on the path between the source and the destination. Nonexistent paths will be indicated by an empty vector. For single destinations, the path is represented by a single vector of vertices, and will be length 0 if the path does not exist.
For ShortestPathAlgorithms that compute all shortest paths for all pairs of vertices, paths(state) will return a vector (indexed by source vertex) of vectors (indexed by destination vertex) of paths. paths(state, v) will return a vector (indexed by destination vertex) of paths from source v to all other vertices. In addition, paths(state, v, d) will return a vector representing the path from vertex v to vertex d.
The structure used to configure and specify that shortest_paths should use the Shortest Path Faster Algorithm. No additional configuration parameters are specified or required.
Implementation Notes
SPFA supports the following shortest-path functionality:
The structure used to configure and specify that shortest_paths should use the Shortest Path Faster Algorithm. No additional configuration parameters are specified or required.
Implementation Notes
SPFA supports the following shortest-path functionality:
Partition sources using Graphs.unweighted_contiguous_partition and place the i^{th} partition into queue_list[i] and set to empty_list[i] to true if the i^{th} partition is empty.
Partition sources using Graphs.unweighted_contiguous_partition and place the i^{th} partition into queue_list[i] and set to empty_list[i] to true if the i^{th} partition is empty.
Note that after importing or usingGraphs.Parallel, you must fully qualify the version of the function you wish to use (using, e.g., Graphs.betweenness_centrality(g) for the sequential version and Parallel.betweenness_centrality(g) for the parallel version).
The following is a current list of parallel algorithms:
Centrality measures:
Parallel.betweenness_centrality
Parallel.closeness_centrality
Parallel.pagerank
Parallel.radiality_centrality
Parallel.stress_centrality
Distance measures:
Parallel.center
Parallel.diameter
Parallel.eccentricity
Parallel.radius
Shortest paths algorithms:
Parallel.bellman_ford_shortest_paths
Parallel.dijkstra_shortest_paths
Parallel.floyd_warshall_shortest_paths
Paralell.johnson_shortest_paths
Traversal algorithms:
Parallel.bfs
Parallel.greedy_color
Also note that in some cases, the arguments for the parallel versions may differ from the serial (standard) versions. As an example, parallel Dijkstra shortest paths takes advantage of multiple processors to execute centrality from multiple source vertices. It is an error to pass a single source vertex into the parallel version of dijkstrashortestpaths.
Compute the shortest paths between all pairs of vertices in graph g by running [dijkstra_shortest_paths] for every vertex and using an optional list of source vertex sources and an optional distance matrix distmx. Return a Parallel.MultipleDijkstraState with relevant traversal information.
Provide a parallel breadth-first traversal of the graph g starting with source vertex s, and return a parents array. The returned array is an Array of Atomic integers.
Implementation Notes
This function uses @threads for parallelism which depends on the JULIA_NUM_THREADS environment variable to decide the number of threads to use. Refer @threads documentation for more details.