Does Heavy Light Decomposition have any advantage over Binary Lifting Technique or using a sparse table? Can we solve some type of problem using HLD which can't be solved using the other mentioned techniques?
# | User | Rating |
---|---|---|
1 | tourist | 3985 |
2 | jiangly | 3814 |
3 | jqdai0815 | 3682 |
4 | Benq | 3529 |
5 | orzdevinwang | 3526 |
6 | ksun48 | 3517 |
7 | Radewoosh | 3410 |
8 | hos.lyric | 3399 |
9 | ecnerwala | 3392 |
9 | Um_nik | 3392 |
# | User | Contrib. |
---|---|---|
1 | cry | 169 |
2 | maomao90 | 162 |
2 | Um_nik | 162 |
4 | atcoder_official | 161 |
5 | djm03178 | 158 |
6 | -is-this-fft- | 157 |
7 | adamant | 155 |
8 | awoo | 154 |
8 | Dominater069 | 154 |
10 | luogu_official | 150 |
Does Heavy Light Decomposition have any advantage over Binary Lifting Technique or using a sparse table? Can we solve some type of problem using HLD which can't be solved using the other mentioned techniques?
Name |
---|
Hld is useful when u are given some kind of non-invertible operation queries with updates. For example, consider the problem witht the following 2 queries:
Update the value of node X to Y
Say the GCD of the path u...v
Can this be done in some other way ?
Ah ok, so it should be used when we need to support update queries. That didn't strike me for some reason. Thanks!
Apart from update queries, ofc:
HLD: O(N) preprocessing, O(logN) LCA query, O(N) memory.
Binary lifting: O(NlogN) preprocessing, O(logN) LCA query, O(NlogN) memory.
Sparse table on DFS order: O(NlogN) preprocessing, O(1) LCA query, O(NlogN) memory.
Segment tree on DFS order: O(N) preprocessing, O(logN) LCA query, O(N) memory.
It's easy to see that HLD beats binary lifting by any means (except for simplicity which is actually quite important in CP), sparse table has a better query time but worse preprocessing time and memory complexity while segment tree gives you the same complexities. Not sure if the constant factor for querying segment tree is bigger than the one for LCA query in HLD but I guess so.
HLD: O(N) preprocessing, O(logN) LCA query, O(N) memory.
What do you mean by LCA query? LCA can be calculated in O(logN) irrespective of HLD/sparse tables, right?
Maybe I have misunderstood what you meant but if you mean query a given path using HLD, that can take O(logN*logN) time, because you may encounter at most logN light edges and for each light edge you will perform a query on the segment tree representing the heavy path above it.
What I mean by LCA query is find the LCA of two nodes. You can do it with HLD, simply bringing one of the nodes to the next chain, depending on which one is deeper until they happen to be in the same chain.