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

Undirected graph #61

Open
marco-foscato opened this issue Nov 27, 2021 · 2 comments
Open

Undirected graph #61

marco-foscato opened this issue Nov 27, 2021 · 2 comments
Labels
redesign Changes in the design of the software

Comments

@marco-foscato
Copy link
Member

Speculative thread on the possibility to make the graph undirected. It is at all possible?
Some notes and comments on this possibility:

  • Edges should become undirected: no more distinction between "source" and "target" ends.
  • The concept of graph's seed (root) vertex would be lost. This is used to identify scaffold, but in a undirected graph the role of the scaffolds can be lost. Meaning that the scaffolds are the starting point when building a graph, and having them isolated allows to guarantee that all graphs have a scaffold vertex (e.g., the metal center in a transition metal complex). So, with an undirected graph with no seed vertex there is need for a mechanism to ensure all graphs have a required vertex. New graph builds, as well as genetic operators must comply to this mechanism.
  • mutation and crossover on branches will have to decide which side of an undirected edge is going to be kept/edited.
  • the conversion to molecular representation using stiff 3D building blocks for ring-closing conformational reaches results in sligtly different geometries for isomorfic (undirected) graphs.
  • in visualizing the graph with JUNG2 will require multiple edge labels, and a customized renderer (vv.getRenderContext().setEdgeLabelRenderer( yourEdgeLabelRendererHere );
@marco-foscato marco-foscato added the redesign Changes in the design of the software label Nov 27, 2021
@marco-foscato
Copy link
Member Author

In many case the getEdgeToParent is just the result of knowing that there can be only one connected vertex. For example, when getting the parent vertex of capping or ring-closing vertexes.

@marco-foscato
Copy link
Member Author

Even if in an undirected graph it would be possible to define rings of vertexes without the need of ring-closing vertexes, the latter save us from the possibility of having multiple edged between vertexes (i.e., a ring involving only 2 vertexes) and loops (i.e., a vertex connected with itself: a ring involving only one vertex). These two features are not to be excluded in general because if the APs involved in the formation of the edges are located on different and disconnected atoms (disconnected even if the two atoms belong to different vertexes), then the multiple edge is a ring involving atoms that belong to different vertexes, and the loop is just a new ring involving only atoms that belong to the single vertex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
redesign Changes in the design of the software
Projects
None yet
Development

No branches or pull requests

1 participant