Conversation
anselrognlie
left a comment
anselrognlie
left a comment
There was a problem hiding this comment.
✨ 💫 Looks good, Ivette! I left some comments on your implementation below.
🟢
| outputs = {} | ||
|
|
||
| res = [] |
There was a problem hiding this comment.
We don't really need two separate places to store the results. Since we are building up P(n) from smaller P() values, as long as we calculate the them in a strictly increasing order (as you do), we could store them in order in an array for later lookup. Using a dictionary can be more helpful if the repeated calculations happen in a less predictable order (often when we are using a recursion+memoization approach).
The other thing you're using the two representations for is to store the numerical result in one, and the string representation in the other. We could covert the numerical values to strings as part of joining them together by using map or a list comprehension.
Otherwise, great approach!
| outputs[n] = value | ||
| res.append(str(value)) | ||
|
|
||
| return " ".join(res) |
There was a problem hiding this comment.
As mentioned above, we could store the numerical values in res for use during the calculation. But since the str join method only knows how to join together strings, we need to convert them from ints. We could accomplish this with methods resembling the following:
return " ".join(map(str, res))or
return " ".join(str(num) for num in res)| Time Complexity: O(n) | ||
| Space Complexity: O(n) |
There was a problem hiding this comment.
✨ Great! We do only make one pass over the desired number of terms during the calculation. The the join call also iterates through the string results, giving us O(2n) → O(n) for time. There is a cost we could try to account for in stringifying the numerical values (they get longer as the numbers get larger) but we can ignore that for the purposes of this exercise.
Storage-wise, we do need n items both in the dictionary and list, as well as the final returned string for O(3n) → O(n), again being a little hand-wavey with the overall size of the final string (and ignoring the sizes of the intermediate strings).
| Time Complexity: O(n) | ||
| Space Complexity: O(1) |
There was a problem hiding this comment.
✨ Notice how better time complexity this approach achieves over a "naïve" approach of checking for the maximum achievable sum starting from every position and every length. The correctness of this approach might not be apparent, so I definitely encourage reading a bit more about it. This has a fairly good explanation, as well as a description of why this is considered a dynamic programming approach (on the face it might not "feel" like one).
Since like the fibonacci sequence, we are able to maintain a sliding window of recent values to complete our calculation, we can do it with a constant O(1) amount of storage.
| @@ -1,12 +1,25 @@ | |||
|
|
|||
| from json.encoder import INFINITY | |||
There was a problem hiding this comment.
👀 The INFINITY symbol is really just an alias for float('inf'), which you can access without needing to import anything from the json module.
| return 0 | ||
| pass | ||
|
|
||
| maximum = - INFINITY |
There was a problem hiding this comment.
Another approach would be to initialize maximum to some value actually found in the list, say nums[0], which we know must at least exist from the guard checks.
| maximum = - INFINITY | ||
| current_max = 0 | ||
|
|
||
| for num in nums: |
2 participants
No description provided.