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

feat: Branch mst #74

Closed
wants to merge 7 commits into from
Closed

feat: Branch mst #74

wants to merge 7 commits into from

Conversation

junnengsoo
Copy link
Collaborator

Do not merge, Prim's README not updated

@junnengsoo junnengsoo linked an issue Jan 31, 2024 that may be closed by this pull request
Closed
@@ -0,0 +1,13 @@
# Prim's Algorithm
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yup fill this up!

Could you also dedicate a section to briefly discuss the slight difference in how a PriorityQueue/heap is used (specifically, the updating of nodes) in dijkstra and prim's? their implementation is actually very very similar, the key difference lies in that dijkstra sums up edge weights cumulatively whereas prim's replaces known shortest weight to an unexplored node

@@ -0,0 +1,13 @@
# Prim's Algorithm

## Background
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be helpful to explain what the queue intuitively stores. It should store distance/edge weights from known set S (nodes that are part of MST) to unexplored nodes.

But, do also mention that implementation-wise, this isn't always uphold. Because to strictly enforce this, would mean for any unexplored node in the queue, if a shorter distance from any of the explored nodes is found, we would need to update the distance to the unexplored node tracked in the queue. In practise, we don't do this but simply add (new_shorter_dist, node) to the queue, while leaving the old data in the queue (Hence, the explicit need to check if a node is alrwady explored when we poll from the queue). This doesn't worsen complexity because in the worst case of E = V^2 edges, log(V^2) = 2log(V).

@@ -0,0 +1,13 @@
# Prim's Algorithm
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe can also squeeze in this little tip that could be helpful in remembering the difference:
prim's - Find MST by growing 1 connected component. Queue tracks distance from this growing component to unexplored nodes, and iteratively explore nodes that are closest of this growing component.

kruskal's - Sorted edges by weight and identify connectivity using some Union Find / Disjoint Set structure

PriorityQueue<Node> pq = new PriorityQueue<>((a, b) -> a.getCurrMinWeight() - b.getCurrMinWeight());

// Values in the map represent the corresponding node with only the edges in the MST
Map<Node, Node> nodeToMSTNode = new HashMap<>();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't quite remember our discussion from before or if there are any concerns you brought up. Because, conventionally, we would use a 2D array for adjacency matrix or a Map<Node, List> for adjacency list

int[] weights = new int[v];
while (!pq.isEmpty()) {
Node current = pq.poll();
current.setVisited(true);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

notice u did not have an explicit check to see if current has already added as part of the MST. reason u do not need to do is because u use remove() method of PQ. See below for why this is discouraged


System.arraycopy(adjM[0], 0, weights, 0, v);
if (!adjacent.isVisited() && weight < adjacent.getCurrMinWeight()) {
pq.remove(adjacent);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove() is actually not a typical operation supported by heap / PriorityQueue (see the GitHub notes on Heap).

While java implementation includes a remove operation (for convenience), this remove will ultimately incur O(n) since a heap (if not augmented), can do no better but O(n) to first search for the node before proceeding with removal.

@junnengsoo
Copy link
Collaborator Author

Changes moved to new PR.

@junnengsoo junnengsoo closed this Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MST
2 participants