-
Notifications
You must be signed in to change notification settings - Fork 69
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
Pine ~ Alma Becerril Salas #43
base: master
Are you sure you want to change the base?
Conversation
Grabbing this to grade! |
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.
Good work!
I left some comments about your time and space complexity calculations for both adding nodes and finding values, but overall, this looks fine enough for a Green.
@@ -1,3 +1,8 @@ | |||
from logging import root | |||
from multiprocessing.sharedctypes import Value | |||
from unittest import result |
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.
It looks like none of these import
statements got used. My guess is that they were added by your IDE when something was autocompleted, but it's good practice to remove them if you don't end up using them to just keep your code clean.
current_node.left = self.add_helper(current_node.left, key, value) | ||
else: | ||
current_node.right = self.add_helper(current_node.right, key, value) | ||
return current_node |
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.
This implementation of add_helper works, but definitely does a bit of extra work in setting nodes. Essentially, every node on the path to where the new node ends up will have either its left or right node "updated", though most of these will be updated to the exact same node. The only one that gets a meaningful update is whenever the bottom of the tree is reached and gets its left/right node updated to the new node. These updates happen in lines 28 and 29.
This probably will not be too bad of a performance hit, but there is a way that you can do this and just update only the node you need.
But this overall fine enough!
return current_node | ||
|
||
# Time Complexity: O(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.
We don't need to go through every node in the tree as would be implied by O(n), but instead follow the tree down however many levels it has. In the case of a balanced tree (a reasonable assumption), we will have to only go down ceiling(log_2(n)) levels, thus having O(log(n)) for both space and time complexity.
Of course, if the tree is not balanced, your calculation is correct, as the worst case, every item is on its own level and thus O(n).
# Space Complexity: | ||
|
||
# Time Complexity: O(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.
Much like as discussed for adding nodes, we don't have to go through each node to find one, but only O(log(n)) nodes. Your answer of O(n) does apply in the worst-case unbalanced tree, though.
As far as space complexity, as no new space is allocated, this is O(1).
No description provided.