Skip to content

Euclidean generator and tsp enhancements#467

Open
megyhazy wants to merge 15 commits intoboostorg:developfrom
megyhazy:euclidean_generator_and_tsp_enhancements
Open

Euclidean generator and tsp enhancements#467
megyhazy wants to merge 15 commits intoboostorg:developfrom
megyhazy:euclidean_generator_and_tsp_enhancements

Conversation

@megyhazy
Copy link
Copy Markdown

@megyhazy megyhazy commented Apr 4, 2026

Thoughts:

  • Generates complete graph. Does this need to be in the prototype name?
  • There is an example that prints graphs and executes an MST algorithm. Maybe unnecessarily complex and can be removed.
  • This is the beginning of refactoring the TSP heuristics to be more modular and have re-usable components vs the way it is now. I intend to refactor metric_tsp and then add nearest_neighbor
  • This is related to issue Euclidian Random Graphs Utilities #452

Addressed earlier comments:

  1. Added test and example to Jamfiles
  2. To euclidean_graph_generator.hpp: Added BOOST_CONCEPT_ASSERT((MutableGraphConcept < VertexListGraph >));
  3. To euclidean_graph_generator.hpp: Removed unused type declarations, PointType / CoordType
  4. To euclidean_graph_generator.hpp: Added assert to compare size of points and graph.

@megyhazy megyhazy marked this pull request as ready for review April 4, 2026 22:18
@jeremy-murphy
Copy link
Copy Markdown
Collaborator

jeremy-murphy commented Apr 14, 2026

Hey, thank you, this looks great!

I'm just wondering about how generic to make it now or later. I'm thinking along two separate lines:

  • the difference between a euclidean and non-euclidean graph is entirely in the distance calculation, meaning most of the code for generating a random graph is the same
  • Boost.Geometry is an obvious choice for representing geometry in the first place, so I want their users to easily be able to provide data without converting their types.

The Boost.Geometry syntax is distance(a, b), so I'm more inclined to make our code do the same thing, such that a Boost.Geometry point type will just work, which I guess means that we define distance(boost::simple_point, boost::simple_point) to use std::hypot and use distance(a, b) in our code. This actually solves both problems at once, because euclidean and non-euclidean points in Boost.Geometry have the same interface. I guess it means that these functions would no longer be specific to euclidean geometry and so they would be better named make_geometric_graph, etc.

What do you think? I don't want to hold up your work for too long but I think this should actually be a fairly small change for a big flexibility.

Edit: Removed my stupid comment before anyone noticed. :)

@jeremy-murphy jeremy-murphy self-assigned this Apr 14, 2026
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

Successfully merging this pull request may close these issues.

2 participants