3

As I know, Object in Javascript acts like a hash (associative array). Therefore, I think the time complexity will be always O(1) when I get a value by a key in an Object like this obj['a'], no matter how many keys in obj. However, an interviewer challenged me about this.

He gave me a question: find the intersection between two unsorted arrays (no duplicate).

My solution is that go through the first array and create hash for every elements, and then loop the second array, if elements in second array are in hash, then push it to output.

The code likes this:

function findIntersection(ary1, ary2) {
  var hash = {};
  var output = [];

  ary1.forEach((v) => {
    hash[v] = true;
  });

  ary2.forEach((v) => {
    if (hash[v]) {
      output.push(v);
    }
  });

  return output;
}

I explained that the complexity is O(m+n), m and n are the length of input arrays. But the interviewer seemed not agree this. He kept ask that are you sure hash[v] to get a value is O(1), tell me how Javascript achieves hash[v].

Is the time complexity of hash[v] not O(1)? If it's not, how to re-write my code to achieve linear time complexity using correct hash structure ?

This struck at the very foundations of my Javascript learnings.

user1884378
  • 63
  • 1
  • 3

1 Answers1

3

This is not about Javascript, it is about "Hash Maps" in general.

They are so called pseudo-constant. It means that for low amount of numbers and in most cases they return you value in constant time, but it is not guaranteed.

What if two strings have the same hash? Then they are saved in one place and you have to go lineary through them to find your value. So if you are unlucky, you can have all keys with hashmap with same hash = result is O(n).

Also when you adding more and more numbers, the probability of collision is increasing, so for a lot numbers you end up with O(n).


About solution - I think the one you have is best for reasonable amount of values (like milions, maybe even billions or less, but not some super-high numbers). It is just good to mention these boundaries in which your algorithm is working corectly.

For finding the duplicates I think there is no algorithm that runs in linear time. You can do it with n log n by sorting it and going through

libik
  • 22,239
  • 9
  • 44
  • 87
  • 1
    Thanks for your explanation. About the solution, maybe it's better to mention the time complexity will be linear for reasonable amount of values for interviewer. – user1884378 May 10 '18 at 02:09