-
Notifications
You must be signed in to change notification settings - Fork 51
Spruce - Angela Fan #31
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨💫 Nice job on your implementation, Angela. I left some comments below.
You left the comprehension questions blank, and had a test problem, so I'm grading this as a yellow for now. But please feel free to resubmit if you'd like me to take another look.
🟡
Time Complexity: O(log n) | ||
Space Complexity: O(log n) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨ Great! In the worst case, the new value we're inserting is the new root of the heap, meaning it would need to move up the full height of the heap (which is log n levels deep) leading to O(log n) time complexity. Your implementation of the heap_up
helper is recursive, meaning that for each recursive call (up to log n of them) there is stack space being consumed. So the space complexity is also be O(log n). If heap_up
were implemented iteratively, this could be reduced to O(1) space complexity.
Time Complexity: O(log n) | ||
Space Complexity: O(log n) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨ Great! In the worst case, the value that got swapped to the top will need to move all the way back down to a leaf, meaning it would need to move down the full height of the heap (which is log n levels deep) leading to O(log n) time complexity. Your implementation of the heap_down
helper is recursive, meaning that for each recursive call (up to log n of them) there is stack space being consumed. So the space complexity is also be O(log n). If heap_down
were implemented iteratively, this could be reduced to O(1) space complexity.
removed_element = self.store.pop() | ||
# Reheapify the heap | ||
self.heap_down(0) | ||
return removed_element |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀 We shouldn't return the internal node that we made for the heap. Instead, just return the value here. Returning the entire node was part of what was causing a test failure.
return removed_element.value
""" | ||
pass | ||
return len(self.store) == 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember that an empty list is falsy
return not self.store
Time complexity: O(log n) | ||
Space complexity: O(log n) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨ Yes, this function is where the complexity in add
comes from.
pass | ||
if index == 0: | ||
return | ||
if self.store[index].key < self.store[(index - 1) // 2].key: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notice that you repeated the (index - 1) // 2
calculation a few times. Consider performing that once and storing it in a local variable.
if index * 2 + 1 < len(self.store): | ||
if index * 2 + 2 < len(self.store): | ||
if self.store[index * 2 + 1].key > self.store[index * 2 + 2].key: | ||
if self.store[index * 2 + 1].key < self.store[index].key: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀 The one we want to swap is the smaller of the two children. This will swap the larger of the two children. This is the other part causing the test failure for the remove ordering.
self.swap(index, index * 2 + 1) | ||
self.heap_down(index * 2 + 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀 Notice that the branches that do anything all culminate in swapping with an index and the making the recursive heap call on that other index.
Consider restructuring so that we calculate what the other index is, and then we could write the swap and heap calls just once.
Time Complexity: O(n log n) | ||
Space Complexity: O(n) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨ Great. Since sorting using a heap reduces down to building up a heap of n items one-by-one (each taking O(log n)), then pulling them back out again (again taking O(log n) for each of n items), we end up with a time complexity of O(2n log n) → O(n log n). While for the space, we do need to worry about the O(log n) space consume during each add and remove, but they aren't cumulative (each is consumed only during the call to add or remove). However, the internal store for the MinHeap
does grow with the size of the input list. So the maximum space would be O(n + log n) → O(n), since n is a larger term than log n.
Note that a fully in-place solution (O(1) space complexity) would require both avoiding the recursive calls, as well as working directly with the originally provided list (no internal store).
while len(heap.store) > 0: | ||
sorted_list.append(heap.remove().value) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should treat the internal store as an implementation detail and not check its length directly. Instead, we can make use of the empty
helper method. Also, note that the value
should be returned by the remove
function, not the whole node.
result = []
while not heap.empty():
result.append(heap.remove())
return result
sorted_list.append(heap.remove().value) | ||
|
||
return sorted(sorted_list) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👀 You already sorted the list by adding and removing with the heap. No need for the sorted
call here.
Heaps Practice
Congratulations! You're submitting your assignment!
Comprehension Questions
heap_up
&heap_down
methods useful? Why?