Skip to content

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

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

C16 - Gabe K #42

wants to merge 6 commits into from

Conversation

GabeKelemen
Copy link

No description provided.

@chimerror
Copy link

Grabbing this to grade!

Copy link

@chimerror chimerror left a 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

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

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)

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).

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)

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.

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.

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.

2 participants