If you are having difficulty understanding this or wrapping your head around the solution, maybe this might be a good way to think about it. The question asks how many subarray sum equals to k. For a subarray to sum to k, you need a subarray, as in a part of the array from index 'a' to index 'b' to have a sum equal to k. But when we reach any index 'b', we obviously do not know, if there was a subarray from index 'a' to index 'b' equal to k. However we do have the sums from 0 to index 'a' in our hash map, because we have been storing all sums starting from index '0' to every single index till now, and the count of them as the value of the key. Now obviously sum_0_to_a + sum_a_to_b = total sum so far (curSum). If we go to the original ask, which is we need a prefix that is sum_a_to_b to be equal to k. For that to hold true, replace sum_a_to_b with 'k'. Hence, sum_0_to_a + k = curSum. Hence curSum - k = sum_0_to_a. And then since we have been storing all possible values of sum_0_to_a so far in the hashmap, curSum - k must exist in the hashmap as a key, and we can simply add the value from the hashmap to add number of prefixes from 0 to any index which equalled to curSum - k .
You know I remember first learning CompSci, I thought the specific algorithm concepts (BFS, DFS, Dijkstra, etc.) were the hard ones to learn. Now that I am more experiences, I realize that the what I thought then were 'basic' data structures, i.e. arrays, strings, etc. are actually the harder ones to make sure you understand because those concepts has many dedicated algorithms to them, such as Kadane, prefix/suffix array, KMP etc. that you need to know to truly understand that data structure. So while I glossed over arrays because I knew their functions, I am now revisiting to make sure I understand the algorithms embedded in them. Learning truly never does stop!
Honestly same here. I figured that arrays would be relatively simple, and they are simple on the surface, but there are so many algorithms and different types of problems that involve them that it feels like they're an entire rabbit hole unto themselves.
Thanks, NeetCode for these solutions and explanations, It would be really helpful to make a video about general techniques that you use to solve these problems... Because we wan to know how to approcah these kinds of problems by ourselves. Thanks again.
Good explanation and, fortunately, the omission of the [key = 2, count = 1] map entry did not affect the result. However, it would be good if NeetCode could add text at that part in the video to make it clear what happened.
We cannot. These are classic problems asked during interviews. Whoever come across this problem would easily solve it. Other would go with bruteforce approach which doesn't work on interviews.
@@darshana5254 thanks bro, you’ve raised a very important point. Only if one has encountered such problems, only then will he be able to solve the problem cuz he knows how to optimum approach.
I got this question in the interview and I did not know the optimal solution. However I was able to produce the n^2 solution quickly and the interviewer started giving me hints to use Hashmap to reduce it to O(N). I scrambled here and there but was able to talk about the "repeated work" being done and how I could use hashmap to save the work. In the end I was not able to code it up. Interviewer still passed me though.
I thought about it as a sliding window problem until I found out there can be negative values. If we would only have positive ones, you would increment right pointer while sum is less than k, then increment left while sume is more than k. That would be my approach (not tested).
@@ziomalZparafii the main problem behind sliding window approach is some edge cases. For example: [1,-1,0], k = 0 If we will use two pointers approach (or dynamic sliding window), then we will return 2 instead of 3. 1) sum=1, count=0, left=0, right=0 2) sum=0, count=1, left=1, right=1 3) sum=0, count=2, left=2, right=2
@@ziomalZparafii you still can use a sliding window with negative numbers, it depends on requirements and edge cases, so your first comment is not entirely accurate.
08:21 - i have no idea how we are supposed to figure out during the coding interview that (0,1) has to be added into the hashmap by default. How is anyone solving this without memorizing during interviews? May be i'm dumb to not understand this even though the instructor is explaining it. Please help me understand the intution behind adding (0,1) in hashmap by default.
i appreciated you explaining this. But, it would have been more helpful(esp to people like me) where you would have taken the time to explain more about the use of HashMap for maintaining prefixSum -> Count to me it felt like the explanation went "too fast" as soon as you discussed the brute force solution.But, in any case a great attempt indeed.
A slightly cleaner solution using a defaultdict class Solution: def subarraySum(self, nums: List[int], k: int) -> int: prefixSums = defaultdict(int, { 0 : 1 }) curSum = 0 res = 0 for n in nums: curSum += n res += prefixSums[curSum - k] prefixSums[curSum] += 1 return res
I understood this explanation! Thanks!! I was trying with sliding window technique first and getting the wrong answer until I realised that we can have negative numbers. This is indeed is a neat.
Another way to think about why we would set our key value to {0:1} instead of memorizing, is to think what if that single element, itself is the target. For example: input = [1, 1, 4] , k = 4 occur = { 0: 1 } By just eyeballing, you'll see the output is 1, since the last element is a 4. When we iterate through the input, we'll do input[2] - k (4 - 4) = 0. Do we have a 0 in our hashmap/dictionary? Yes we do, it's value is 1.
except in this scenario wouldn't we be doing currSum - k (6 - 2) = 2, and we would be looking up the value for 2 in our hash map, which would be 1. I think your scenario only works if the single element that is the target is the first element in the input.
so what you are saying is we have a map that shows how many ways we can come up with given sum so for sum 0 we can come up with 2 sequences, but these sequences have to be contiguous , how to prove that 0 has 2 only if we pop up contiguous elements from current sum ?
Finally a great explanation what hashmap actually represents! Got the essentials of the algorithm on the first watch of this video, but was banging my head against the wall trying to figure it out on leetcode.
Hi @NeetCode. I am not able to understand the part where you say. we need to add the prefix sum to Hashmap simultaneously. even if are maintaining the Hashmap first. we can still get count of prefix - k and prefix = k.
Take this example: [1]; k = 0. Without adding first your prefix sum array would be: 0->1 and 1->1. Now you will compute prefixSum-k for each key. 0 - 0 = 0, You say you have a match(which is just the empty prefix). Now you compute 1- 0 = 1, you check your map and the value exists, so you return a count of 2. That is why the update needs to happen simultaneously. So, that you can check the subarray between some starting index "i" and current index "k"(excluding k). Hope this makes sense.
I am not sure, but take an example where the array is [-1,1,-1] and k>0(e.g., 2). The result would be 1, since after the 1 is covered, and then we went into the -1 again, the result will be 1, and that's not true (should be 0). Am I missing something? I think the results should be added only if the cursum is >=k
I see some confusion on why we initialize prefixSum = {0:1}, and that's because we can always produce 0 by taking no elements from our array (e.g. []). This works out nicely when we run into a subarray that has a sum == k, because sum - k = 0. Then the question we ask at this moment is "is there a prefix-subarray I can take away from my current subarray sum that also equals 0?" The answer is yes, because I can takeaway no elements from my current subarray and the current subarray sum will still equal k.
Did this problem but used an array to keep track of the running totals then reversed it... used a deque after but wow is deque slow and memory intensive
I have a doubt. If the array is 6,4,3 and k is 9. we find that sum till n is 13 and 13-k ie 13-9=4 is present in the array so that will get counted but in reality it is wrong as it is not a subarray is we dont pick contiguous element. please explain
Why doesn't sliding window approach fails here: - Assumption: adding an element to increase and removing an element to decrease any sum is valid only if all elements are non-negative. - removing negative elements increases total sum and vice versa, hence breaks tests containing negative number - not suitable approach for this problem
Added more comments, explanation, changed diff to prevSum which I think makes it easier to understand: class Solution: def subarraySum(self, nums: List[int], k: int) -> int: kCount = 0 curSum = 0 prefixSums = {0:1} for n in nums: curSum += n # We are at curSum, but we want to know how many sum = k # have occurred. k = curSum - prevSum, use the prefixSums # hashmap to determine how many prevSums occurred. Each # one represents a potential subarray that could be # subtracted to reach sum = k. prevSum = curSum - k kCount += prefixSums.get(prevSum, 0) # Update prefixSums AFTER we have gotten the kCount for # this curSum. We ensure that kCount considers only # prevSums prior to this iteration. Including this sum # potentially doublecounts the n of this iteration, # using the n in both curSum and prevSum. prefixSums[curSum] = 1 + prefixSums.get(curSum,0) return kCount
I don't understand why you kept Prefix Sum of 0 and count 1 when you started over and changed the index 1 element from 1 to -1. It's a new example, why did you not reset the hash table?
My python implementation: class Solution(object): def subarraySum(self, nums, k): """ :type nums: List[int] :type k: int :rtype: int """ occur = collections.defaultdict(int) occur[0] = 1 count = 0 cur_sum = 0 for n in nums: cur_sum += n if cur_sum - k in occur: count += occur[cur_sum-k] occur[cur_sum] += 1 return count
Yeah it's complicated but don't forget to come up with the optimal solution in 10 minutes without any compiler errors and of course it needs to pass all test cases in the interview. smh. Tech interviewing has become a circus.
