You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 21, 2021. It is now read-only.
The methods vertex_index and edge_index are used to map an vertex or edge into an integer index, which can then be used to get the attributes from an array (or an array-like object). The index can be directly stored within the vertex or in a map associated with the graph.
Some recent applications indicate that this approach might not be flexible enough, especially in a dynamic context where vertices/edges can be added or removed after a graph is constructed.
I think @deinst's property inspector might be a better way forward. For example, for Diijkstra's algorithm, instead of requiring the graph to implement the edge_map interface, we require the user of the algorithm to supply a weight map object that implements the following method:
get_edge_attribute(p, v, g)
# p: the property inspector object# v: the vertex # g: the graph
This may probably make removal or temporary censoring of vertices or edges easier.
With this new interface, we no longer require vertices to be added such that their indexes are in consecutive ascending order. This also provides greater flexibility in some applications.
This seems doable (I had started something along these lines in my last PR.) I'll play with it a bit. First, I want to get things working with graphs where the vertices and edges are unindexed (these are useful in the majority of cases where convenience and ease of use are of more importance than mindblowing speed)
In a lot of algorithms, we have to use vertex or edge as indices to retrieve corresponding attributes such as colors and weights.
In my original design, this is through the
vertex_map
andedge_map
interface. This is how it works:The methods
vertex_index
andedge_index
are used to map an vertex or edge into an integer index, which can then be used to get the attributes from an array (or an array-like object). The index can be directly stored within the vertex or in a map associated with the graph.Some recent applications indicate that this approach might not be flexible enough, especially in a dynamic context where vertices/edges can be added or removed after a graph is constructed.
I think @deinst's property inspector might be a better way forward. For example, for Diijkstra's algorithm, instead of requiring the graph to implement the
edge_map
interface, we require the user of the algorithm to supply a weight map object that implements the following method:This may probably make removal or temporary censoring of vertices or edges easier.
With this new interface, we no longer require vertices to be added such that their indexes are in consecutive ascending order. This also provides greater flexibility in some applications.
Any thoughts?
cc: @deinst, @kmsquire, @pozorvlak
The text was updated successfully, but these errors were encountered: