You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nice - I agree with your analysis, thank you for clarifying!
Regarding the proposed solution:
Yes I think that works! (:
How intensive is the merge operation? Does the sequential merging take much time? If so, we might be able to optimize it by leveraging the graph structure (forgive the pseudo code):
(1) Creating a set of all nodes with this class label (I'll call it _node_set, _ indicating that it's temporary )
(2) While _node_set is non-empty:
(2.0) Pop the first node in current_node = _node_set.pop()
(2.1) From current_node, do a graph traversal (e.g. bfs) along the nearest neighbors to find all nodes that can be reached from current_node by going through nodes with the same class label. Add those nodes to a list called nodes_to_merge. This will be one cluster of nodes that will be merged into a larger one.
(2.2) Merge all nodes in nodes_to_merge, with the final index of current_node
(2.2) Remove nodes_to_merge from _node_set
This way we'd be doing one "merge" per cluster of nodes (one in the above example), rather than one per neighbors (3 in the above example)
Nice - I agree with your analysis, thank you for clarifying!
Regarding the proposed solution:
Yes I think that works! (:
How intensive is the merge operation? Does the sequential merging take much time? If so, we might be able to optimize it by leveraging the graph structure (forgive the pseudo code):
This way we'd be doing one "merge" per cluster of nodes (one in the above example), rather than one per neighbors (3 in the above example)
Originally posted by @Croydon-Brixton in #70 (comment)
The text was updated successfully, but these errors were encountered: