What is the approximately time complexity of the solution to the below problem? If we assume that due to path compression, each call to self.find() is roughly amortized to ~O(1)
Problem Statement:
Given a list accounts, each element accounts[i] is a list of strings, where the first element accounts[i][0] is a name, and the rest of the elements are emails representing emails of the account.
Now, we would like to merge these accounts. Two accounts definitely belong to the same person if there is some email that is common to both accounts. Note that even if two accounts have the same name, they may belong to different people as people could have the same name. A person can have any number of accounts initially, but all of their accounts definitely have the same name.
After merging the accounts, return the accounts in the following format: the first element of each account is the name, and the rest of the elements are emails in sorted order. The accounts themselves can be returned in any order.
Example: Input: accounts = [["John", "[email protected]", "[email protected]"], ["John", "[email protected]"], ["John", "[email protected]", "[email protected]"], ["Mary", "[email protected]"]]
Output: [["John", '[email protected]', '[email protected]', '[email protected]'], ["John", "[email protected]"], ["Mary", "[email protected]"]]
Explanation: The first and third John's are the same person as they have the common email "[email protected]". The second John and Mary are different people as none of their email addresses are used by other accounts. We could return these lists in any order, for example the answer [['Mary', '[email protected]'], ['John', '[email protected]'], ['John', '[email protected]', '[email protected]', '[email protected]']] would still be accepted.
class Solution:
def accountsMerge(self, accounts):
"""
:type accounts: List[List[str]]
:rtype: List[List[str]]
"""
owners={}
parents={}
merged=collections.defaultdict(set)
results=[]
for acc in accounts:
for i in range(1,len(acc)):
owners[acc[i]] = acc[0]
parents[acc[i]] = acc[i]
for acc in accounts:
p = self.find(acc[1],parents) #Find parent of the first email in the list.
for i in range(2,len(acc)):
#Perform union find on the rest of the emails across all accounts (regardless of account name, as no common email can exist between different names.)
#Any common emails between any 2 lists will make those 2 lists belong to the same set.
currP = self.find(acc[i],parents)
if p!=currP:
parents[currP] = p
for acc in accounts:
p = self.find(acc[1],parents)
for i in range(1,len(acc)):
merged[p].add(acc[i])
for name,emails in merged.items():
res = [owners[name]] + sorted(emails)
results.append(res)
return results
def find(self,node,parents):
if node!=parents[node]:
parents[node] = self.find(parents[node],parents)
return parents[node]
Examine the code, part by part:
for acc in accounts:
for i in range(1,len(acc)):
owners[acc[i]] = acc[0]
parents[acc[i]] = acc[i]
This is O(N), where N is the size of the input text, because the algorithm visits every part of the input exactly once. Note that each text element may have an arbitrary size, but this is taken care of, because N is the size of the input text.
for acc in accounts:
p = self.find(acc[1],parents) #Find parent of the first email in the list.
for i in range(2,len(acc)):
currP = self.find(acc[i],parents)
if p!=currP:
parents[currP] = p
This is also O(N) since:
self.find(acc[i], parents) is considered to be amortized O(1) due to path
compaction.for acc in accounts:
p = self.find(acc[1],parents)
for i in range(1,len(acc)):
merged[p].add(acc[i])
The loops themselves, depend on N - the size of the input text. The add() method operates on a set, which is considered O(1) in python. To summarize, this block also takes O(N).
for name,emails in merged.items():
res = [owners[name]] + sorted(emails)
results.append(res)
Surprisingly, here lies the bottleneck (at least in terms of the O notation). The number of elements in emails is O(N), because it well may be that the system has one big user that has most of the emails. This means that sorted(emails) can take O(N log N).
The part of the code that creates res, after sorting:
res = [owners[name]] + <the sort result>
this is only linear in the size of the sorted data, which is smaller than the O(N log N) of sorting.
Despite being in a loop, the cost of the sorting does not add up to more than O(N log N) overall, because the cost of O(N log N) assumes that there is one big user. There can't be more than a handful big users.
For example, let's say there are K equal users in the system. This makes the sorting cost O(N/K log(N/K)) per user. This totals to O(N log (N/K)) for the whole system. If K is constant, this becomes O(N log N). If K is a function of N, then O(N log(N/K)) is smaller than O(N log N). This is not a rigorous proof, but is enough to get the basic idea why it is O(N log N) and not worse.
NOTE: The complexity calculation has one major assumption that in Python, accessing a map or a set by a string key of length L, is an O(L) operation. This is generally correct, with a perfect hash function, which Python does not have.