Skip to content

Commit 586b3f4

Browse files
No text
1 parent c3b1d74 commit 586b3f4

File tree

1 file changed

+1
-18
lines changed

1 file changed

+1
-18
lines changed

alpha/alpha-algo/src/main/java/org/neo4j/gds/impl/spanningtree/KSpanningTree.java

Lines changed: 1 addition & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -359,26 +359,9 @@ private boolean moveMakesSense(double cost1, double cost2, DoubleUnaryOperator m
359359
}
360360

361361
private SpanningTree combineApproach(SpanningTree tree) {
362-
/*
363-
* these are quick and fast techniques of returning a k-Tree without having to worry about not
364-
* ending up with a tree of k nodes *1, which was the main reason why the existing algorithm did not work.
365-
*
366-
* Teh first approach just cuts leaves from the final MST
367-
* The second approach grows the MST step-by-step and cuts leaves when it needs to trim an edge
368-
*
369-
* Neither of this approach is the best by itself
370-
* (the approach of cutting the heaviest also has its shares of issues ofc)
371-
*
372-
* but it is not hard to construct situations where one works well and the other does not.
373-
* So I thought of combining the two and return the best
374-
*
375-
* This is supposed to be a quick fix to eliminate the bug asap. When we work next time on k-MST,
376-
* we can come up with something more sophisticated (there's optimal algorithms for dealing with subtree;
377-
* but they take O(nk^2) so maybe not good). Otherwise, it's np-complete so...
378-
*/
362+
379363
var spanningTree1 = cutLeafApproach(tree);
380364
var spanningTree2 = growApproach(tree);
381-
System.out.println(spanningTree1.totalWeight() + " " + spanningTree2.totalWeight());
382365

383366
if (spanningTree1.totalWeight() > spanningTree2.totalWeight()) {
384367
return (minMax == Prim.MAX_OPERATOR) ? spanningTree1 : spanningTree2;

0 commit comments

Comments
 (0)