[Py] Improve embeddings #19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to allow for more chain scenarios, e.g. add a random chain where both source and target node are in chains themselves. This led to overcomplicated code having to deal with chains that are placed on edges instead of nodes. Thus, this commit is a working example for better chain placement (although not perfect), but definitely needs to be redone in the next commits (e.g. using the already-used mapping from H to G instead of essentially redundant chains on edges).
This only affects the embedding and solver module.
Beforehand, we encoded supernodes using edge costs, e.g. edge with cost 0 was no chain, an edge with cost 1 indicated that the two nodes mapped to the same node_H, thus they belong to the same supernode. However, this was essentially redundant as we also stored the mapping between input graph H and hardware graph G in the mapping class. We leverage this class now and encode supernodes directly, thus getting rid of edge chains (remnants are still there, will clean up later). It might be worth to keep the term "chain" to indicate supernodes that consist of more than one node. This change makes the embedding itself worse, e.g. K4 does not work anymore. This is since we now also allow to merge random nodes to supernodes where both source and target are in chains. We need to implement the evolutionary strategy where we select the mutation that yields the best result, in our case where the most edges can be embedded (to achieve a "real" local maximum). Also changed: - Changed lists to sets in various places - Adapted drawing class to the new changes (to properly draw supernodes) - Made logging output more precise
Split the method into multiple pieces for better readability and fixed several bugs that occurred due to wrong order of execution. It is still quirky that we can't embed edges freely since all nodes on that edge must have supernode (in the current implementation). That's why there are some special constructs, e.g. we need to discard nodes from sets to make sure not the change results after having embedded them in supernodes. There is room for improvement here. Fixed a really annoying bug: Sets in Python are returned by reference, so we got weird results since we used discard on them assuming we just altered the local variable. Now we copy the set. Fixed another, potential bug where we accidentally added selfloops to the embedding view graph. Also improved error messages.
Note that at this point, we still sometimes use the word "chain", however we don't use chains encoded on edges anymore, but now on nodes themselves. TODO: Unify usage of words "chain" and "supernode" throughout the code.
Also slightly shifted labels of Chimera graph for better readability.
After each generation we also try to remove unnecessary edges.
This way, we don't remove the wrong nodes in our graph that would disconnect the respective subgraph of supernodes (if removed). See https://www.geeksforgeeks.org/articulation-points-or-cut-vertices-in-a-graph/ and https://youtu.be/jFZsDDB0-vo as examples
Previously, we removed all nodes that were not articulation points for every supernode in one go. However, as we remove, the articulation points might change, so we need to recalculate them every time a node is removed.
We don't shift the target node in this strategy.
Also switched to 5x5 Chimera cell
Split into multiple methods for easier understanding.
Beforehand, this mutation was only a surrogate if the other strategy didn't work. We now establish it as full-value mutation and switch between the two mutations based on a random value. This also means that we now make sure in the shifting/bumping mutation that source and target are not from the same supernode since this would undermine the other strategy which is essentially this.
This will remove redundant supernode nodes if no mutation could be found at all in a generation. We will then try to generate new children again.
We disable logging to achieve a better performance and also save less SVG images (every x image instead of every generation). Also tried to tune evolutionary params to get K12 embedded (with no success currently).
We now favor nodes where the supernode has the least number of edges emedded in G compared to how many edges to other supernodes should be embedded. These percentages (actual divided by expected) change the uniform distribution of numpy's random choice function. We now use this new method for both strategies: - extend_random_supernode_to_free_neighbors as well as - extend_random_supernode (by "bumping")
We didn't check whether the target is an articulation point in its own supernode for the "extend_random_supernode (by "bumping")" strategy. This led to a "break-up" of the graphs induced by the respective supernodes of the input graph H.
Also plot the chances with matplotlib
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request failed before (accidentally did not perform a squash merge), so this is the same as PR #18.
Add evo approach, implement articulation point, remove redundant nodes in super vertices, extend super vertices with and without shifting target vertices, add bias to random node selection and much more...