### DmitryGrigorev's blog

By DmitryGrigorev, history, 3 years ago, translation, ,

Can anybody help me with this task: We have a tree with N verteces(N<=5*10^5). Each edge has got a length Li(Li<=1000). In each iteration we delete one(given) of un-deleted edges and we must tell the longest simple way in each of two resulting components and we doing it while all edges aren't deleted. Please, any ideas how to solve it?

• +19

 » 3 years ago, # |   0 Auto comment: topic has been translated by DmitryGrigorev (original revision, translated revision, compare)
 » 3 years ago, # |   0 Auto comment: topic has been updated by DmitryGrigorev (previous revision, new revision, compare).
 » 3 years ago, # | ← Rev. 2 →   +11 First idea is to reverse the problem: instead of deleting edges we can look at the problem from the end and add edges.Now all we need is to merge two trees into one and calculate diameter of a new tree. Consider trees T 1 and T 2 that are going to be connected by an edge (a, b), and let n(T 1) ≤ n(T 2). New diameter is the maximum of d(T 1), d(T 2) and 1 + d 1(a) + d 2(b), where d 1(a) is the maximum distance from a to other vertex in T 1, and d 2(b) is defined in the same way for T 2. Let's maintain these numbers after the merge: for T 1 we recalculate all of values naively, using known d 2(b). But for large T 2 we can't do that. So let's remember that for every vertex x of T 2 to find this distance in future we need to test its distance to a and relax this value by dist(x, a) + d 1(a). Technically, it means that we add this condition for the whole component and iterate over vertices of T 1 to cancel this condition for them. If the tree is merged then with larger tree, we throw away all these conditions. Because of that, we need to maintain only conditions for a component of size k. Because of that the whole algorithm works in .
•  » » 3 years ago, # ^ |   0 I dont understand, why we must maintain only O(logk) conditions?
•  » » 3 years ago, # ^ | ← Rev. 2 →   +42 If we fix a diameter uv of some tree T and a vertex t then either u or v is the furthest vertex from t. Using this, for every component we just keep two ends of its diameter and update them accordingly, so I guess we just got significantly simpler solution.These contribute to resulting complexity: 1) computing O(n) distances, 2) find and union, so overall complexity would be . However if we want to get best theoretical complexity, to first one we can use well known LCA/RMQ thing in constant time per query and to second one if I'm not mistaken it is possible to do F&U in total linear time if we perform it on a planar graph that is known beforehand, so total complexity would be O(n), but you definitely do not want to code this like that ;p.Btw why is your solution in ? Did you already assume we can compute distances in O(1)? I think we are asking distance queries what when done in standard way takes
•  » » » 3 years ago, # ^ | ← Rev. 2 →   0 Yes, you are right. Also my claim about conditions is incorrect, it can be changed to if we rebuild all the stuff each steps. May be too much for this constraints, and your solution is much simpler.Btw, I think we can also solve this problem with centroid decomposition in . The idea is to maintain for each subtree of centroids children the set (distance from centroid, last added edge on path), in which both coordinates are increasing. Then we can add subtrees one by one and relax the answer.
•  » » » 3 years ago, # ^ |   0 Yes, it's simple and beautiful. Thank you very much