Skip to content
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

leetcode/hash-table/TwoSum.java #94

Open
knasim opened this issue Aug 13, 2018 · 6 comments
Open

leetcode/hash-table/TwoSum.java #94

knasim opened this issue Aug 13, 2018 · 6 comments

Comments

@knasim
Copy link

knasim commented Aug 13, 2018

There is a better solution for the TwoSum problem than the hashmap solution. Sure hashmap is fine and meets the desired output. however it can be completely eliminated as such. The techinque employs a pointers to track the argument array i.e. one from the begining aka head and the other one from the end aka tail. A single sweep on the array and adjusting the two pointers does the job rather nicely.

       //input array must be sorted 
       int head =0;  int tail = arr.length -1;  int k = 11;  //target sum to find

        while(head < tail) {
           int sum = arr[head] + arr[tail];
           if(sum == k)  return true; //found it !!
           else if(sum < k) ++head;
           else --tail; 
        }


@kdn251
Copy link
Owner

kdn251 commented Aug 13, 2018

This assumes that the array is sorted which is not the case. Therefore this adds an overhead of O(nlogn) to sort which is slower than O(n)

@knasim
Copy link
Author

knasim commented Aug 14, 2018

right but the hashmap increases use of space. shouldn't we consider the net effect ?

@IAmPramod
Copy link

@knasim Even if we go best sorting algorithm(merge/quick/tree), It will have time complexity O(nlogn)
with worst space complexity O(n).

Using hashmap, we solve this in O(n) time with space O(n) even if all the elements are distinct in the array.

@sragha45
Copy link

@IAmPramod , I reckon hashmap is implemented using Red-Black trees, so the average lookup time for a huge N becomes log N. So for N elements it again comes to O(N log N)

@IAmPramod
Copy link

@sragha45 Yes, you are correct. But O(NlogN) is the worst case scenario when we have a very poor implementation of hash code which will map all entries to same bucket.

Have a look at the performance of hashmap in average case. https://dzone.com/articles/hashmap-performance

@vin0010
Copy link

vin0010 commented Nov 19, 2018

May be this is not completely related to the discussion. But with hash map and tuple together, we can solve this problem easily.

def get_count_map(nums):
        count_map = dict()
        for i in range(0, len(nums)):
            if nums[i] in count_map:
                temp = count_map[nums[i]]
                temp[1].append(i)
                temp = (temp[0]+1, temp[1])
                count_map[nums[i]] = temp
            else:
                count_map[nums[i]] = (1, [i])
        return count_map


    def print_indices(count_map, k):
        for i in count_map:
            if 2*i == k:
                return [count_map[i][1][0], count_map[i][1][1]]
                break
            else:
                if k-i in count_map:
                    return [count_map[i][1][0], count_map[k-i][1][0]]
                    break

https://github.com/vin0010/Competitve-Programming/blob/master/python/leetcode/TwoSum.py

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

No branches or pull requests

5 participants