-
Notifications
You must be signed in to change notification settings - Fork 0
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
01 - methodical problem solving - in-class problems #3
base: master
Are you sure you want to change the base?
Conversation
janiceshiu
commented
Jun 2, 2020
- roman numerals
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.
Looks great, thanks for working on this!
|
||
Analysis | ||
Time - o(n) where n is the length of the string | ||
* no matter what, we have to iterate through each character in the |
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.
Technically twice, but yes, I agree still O(n)!
idx = 0 | ||
str_length = len(string) | ||
|
||
while idx < str_length: |
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! I think this handles the edge cases nicely.
One way you might split things up even more is to introduce a separate function like "should_subtract" or "is_subtractive_pair".
* not very sure. lookup length is constant but we have to go through the whole string as well | ||
* so maybe o(n) where n is length of the string? | ||
* each iteration uses o(k) time to slice the string in `string[len(elem[0]):]` | ||
* also not sure how long `string.startswith` takes |
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.
One way I estimate time complexity for library functions is just to imagine how I'd implement something. The library function should be at least that efficient!
For example, one easy way to implement startswith
is to check each character one by one. So if the string has length n
and the thing you're checking has length m
, the time complexity is likely O(min(n, m)
).
time - o(nk)? | ||
* not very sure. lookup length is constant but we have to go through the whole string as well | ||
* so maybe o(n) where n is length of the string? | ||
* each iteration uses o(k) time to slice the string in `string[len(elem[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.
One suggestion is to write down what n
and k
are, so it's really cleaer.
for elem in lookup: | ||
while string.startswith(elem[0]): | ||
acc += elem[1] | ||
string = string[len(elem[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.
Can you think of a way to improve this (to avoid an expensive slice operation)?
Analysis | ||
time - o(n) where n is length of acc? | ||
* time to iterate through lookup is constant | ||
* however, `''.join(acc)`... does this take o(n) time to iterate through the length of acc? |
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, O(n) for join
makes sense.
eg: IIIII returns V | ||
|
||
Analysis | ||
time & space - combination of roman_to_number_3 and number_to_roman |
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 idea for solving this one!