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

Relabel nodes in canonical order #144

Open
lmondada opened this issue Aug 8, 2024 · 1 comment
Open

Relabel nodes in canonical order #144

lmondada opened this issue Aug 8, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@lmondada
Copy link
Contributor

lmondada commented Aug 8, 2024

For testing and comparing portgraphs, It would useful to be able to reorder a graph's node indices into a canonical order. We could either change the behaviour of compact_nodes to do that, or alternatively introduce an additional e.g. compact_nodes_canonical (the reason for the latter variant is that we might want to pass arguments to the function).

We would need first to discuss what "canonical" should mean:

Canonical ordering of nodes

Given the ordering of port offsets, a Dfs or Bfs traversal gives us a canonical ordering of nodes, up to a choice of start vertex per connected component of the graph (this assumes that directed edges can also be traversed backwards). I can think of a couple of strategies to choose the start vertices

  • order connected components by their number of vertices
  • pick vertices with indegree 0 as start.

This is obviously still not unique, but definitely good enough for me. Choosing the smallest NodeIndex first would be a reasonable tie-breaker. Alternatively, we could let the caller specify a tie-breaking strategy...

@lmondada lmondada added the enhancement New feature or request label Aug 8, 2024
@lmondada
Copy link
Contributor Author

lmondada commented Aug 8, 2024

You could also choose the start vertices that minimise some global property (e.g. the hash of each connected component). This would be very close to unique, but more expensive to compute. In this case you could assume no hash collision and thus no tie-breaker would be required.

Either approach would work for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant