Conversation
anselrognlie
left a comment
There was a problem hiding this comment.
✨💫 Nice job on your implementation, Nourhan. I left some comments below.
You left the comprehension questions blank, so I'm grading this as a yellow for now. But please feel free to resubmit if you would like a green score!
🟡
| Time Complexity: O(logn) | ||
| Space complexity: O(logn) because of the call stack |
There was a problem hiding this comment.
✨ Great. You're exactly right that it's due to the recursive call in heap_up that the space complexity is O(log n). If heap_up were implemented iteratively, this would only require O(1) space complexity since the stack size wouldn't depend on the heap depth.
| Space complexity: O(logn) because of the call stack | ||
| """ | ||
| pass | ||
| self.store.append(HeapNode(key, value or key)) |
There was a problem hiding this comment.
👀 To explicitly handle the case where the value is absent, prefer an explicit check with None
if value is None:
value = keyUsing or would treat any falsy value as being missing, so we could not store False as the value, for example.
| Time Complexity: O(logn) | ||
| Space complexity: O(logn) because of the call stack |
There was a problem hiding this comment.
✨ Nice. Just as for add, you're right that the log space complexity remove is due to the recursive heap_down implementation. We could achieve O(1) space complexity if we used an iterative approach.
| Space complexity: O(logn) because of the call stack | ||
| """ | ||
| pass | ||
| if self.empty(): |
There was a problem hiding this comment.
✨ Nice use of your own helper method!
| if len(self.store) == 1: | ||
| return self.store.pop().value | ||
| minimum = self.store[0] | ||
| self.store[0] = self.store.pop() |
There was a problem hiding this comment.
We could avoid this special case by swapping the first element with the last (moves the minimum to the end, and a larger value to the head), then popping from the end. If there were only one thing left, it would be swapped with itself, then removed.
| Time complexity: O(logn) | ||
| Space complexity: O(logn) because of the call stack |
There was a problem hiding this comment.
✨ Yes, this function is where the complexity in add comes from.
| def get_valid_index_or_none(index): | ||
| if index < len(self.store): | ||
| return index | ||
| else: | ||
| return None | ||
|
|
||
| def get_key_or_none(index): | ||
| if not index: | ||
| return None | ||
| return self.store[index].key |
There was a problem hiding this comment.
✨ Nice helpers. They don't really need to be defined locally to the heap_down function, but that does prevent them from being called from anywhere else. On the one hand I like the protection, on the other hand, local functions can be confusing since they make the reader think about why the function as declared locally. Not really a right or wrong way here, just be sure to follow the style in use by the rest of your team.
| left_key = get_key_or_none(left_index) | ||
| right_key = get_key_or_none(right_index) | ||
|
|
||
| index_to_swap = min((node for node in [(left_index, left_key), (right_index, right_key)] if node[1] is not None ), key=operator.itemgetter(1), default=None) |
There was a problem hiding this comment.
This is a really concise set of steps to filter out the invalid children, then select the minimum! However, it's a bit dense, which makes it a little tough to understand. Consider adding a comment about what it does, break it up into several lines with the intermediate products given descriptive names, or move into a helper function with a descriptive name.
An example of splitting across multiple lines
candidate_children = [(left_index, left_key), (right_index, right_key)] # we could use a tuple rather than a list
valid_children = (node for node in candidate_children if node[1] is not None) # this actually makes a generator function, not a tuple
index_to_swap = min(valid_children, key=operator.itemgetter(1), default=None) | Time Complexity: O(nlogn) | ||
| Space Complexity: O(n) |
There was a problem hiding this comment.
✨ 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).
| sorted = [] | ||
| for item in list: | ||
| heap.add(item) | ||
| for i in range(len(list)): |
There was a problem hiding this comment.
In this situation, since we built the heap, we also "know" the number of items in the heap. So it works to iterate using knowledge about the list. But if we were pulling things out of a heap more generally, we would want to make use of the empty helper as follows:
sorted = []
while not heap.empty():
sorted.append(heap.remove())
return sorted
Heaps Practice
Congratulations! You're submitting your assignment!
Comprehension Questions
heap_up&heap_downmethods useful? Why?