Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BGL: Search Information in Vertex Class #83

Open
marip8 opened this issue Sep 7, 2021 · 0 comments
Open

BGL: Search Information in Vertex Class #83

marip8 opened this issue Sep 7, 2021 · 0 comments

Comments

@marip8
Copy link
Collaborator

marip8 commented Sep 7, 2021

Currently the Vertex class (used for bundled properties in the BGL search methods) holds a subset of the information needed by the search methods (distance and color). Other properties, namely the vertex predecessor, is being managed outside the graph.

template <typename FloatType>
struct Vertex
{
/** @brief State sample information, assigned by user */
StateSample<FloatType> sample;
/** @brief Index of the "rung" of the ladder graph with which this node is associated */
long rung_idx{ -1 };
/** @brief Distance from the start node, assigned graph algorithm at search-time */
FloatType distance{ static_cast<FloatType>(0.0) };
/** @brief Search status "color" of the vertex: visited, opened, unvisited. Assigned by the graph algorithm at
* search-time */
ColorT color{ 0 };
};

For clarity, it seems like the graph should either:

  1. manage all the vertex properties required for the search in the graph
    • Pros:
      • Bundled properties are somewhat easier to manage in the graphs
    • Cons:
      • Some fields of the Vertex class need to be populated by the solver build method and should be held constant during the search (sample and rung_idx), and other methods will be filled out by the search method (color, distance, etc.). This is somewhat confusing and prone to error
  2. all of those properties should be managed outside of the search.
    • Pros:
      • The Vertex class can be composed of only "read-only" members that get populated by the solver build method, which would reduce ambiguity about the class
    • Cons:
      • The containers for the vertex properties must be stored/maintained inside the solver class
      • The property containers would need to be passed to the graph serialization functions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant