-
Notifications
You must be signed in to change notification settings - Fork 68
C16 - Gabe K #42
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?
C16 - Gabe K #42
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 added some comments about some unneeded import
statements, a performance hit with your add implementation, and a few notes on your complexity calculations, but this is good enough for a Green!
@@ -1,3 +1,7 @@ | |||
from multiprocessing.dummy import current_process | |||
from typing import ItemsView |
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.
Look like these import
statements never got used. I'm guessing they got added automatically by autocomplete, but you can delete them regardless.
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 30.
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!
# Time Complexity: | ||
# Space Complexity: | ||
# Time Complexity: 0(log n) | ||
# Space Complexity: 0(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.
Luckily since you did an iterative approach for this, we do not take the hit of the space that will be added to the stack if you had done this recursively. As such, the space complexity is O(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.
Ignore my comment on how there is space complexity savings for a recursive solution. Both should be O(1) in my opinion because they are not using additional space. I was going off the instructor solution and then realized that I think they made a mistake.
# Time Complexity: | ||
# Space Complexity: | ||
# Time Complexity: 0(n) | ||
# Space Complexity: 0(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.
This is true assuming an unbalanced tree, but if we assume a balanced tree, then we only need to recurse down O(log(n)) times along each branch of the tree, so we can use that for the time and space complexity calculations.
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.
When I gave this comment, I was working off the instructor solution, but I now think this is wrong. The time complexity is O(n) regardless because we have to travel to every node, and O(1) regardless because no additional space is allocated.
Sorry for any confusion.
No description provided.