Heavy-Light Decomposition: When to Use It

Start with the idea

A problem is a good match for Heavy-Light Decomposition when it asks for tree path queries with segment trees. Here the concrete task is: Return the sum on path 2 to 4. The visible input edges=(0,1),(1,2),(1,3),(3,4) values=[1,2,3,4,5] is an example, not a definition of the whole problem. Ask what operations the solution must support and what the input guarantees. Choose it when the required operation sequence, query volume, or substring structure exceeds a simple scan or prefix summary; compare the real time and memory limits first. The right choice follows from those guarantees, not from a familiar noun in the prompt.

The decisive invariant is: Choose one heavy child per node so any root path crosses only logarithmically many light edges. Try to say why it applies to the task without quoting the implementation. Which fact becomes known after one update, and which possible answers remain? An advanced structure or offline query order packages an invariant across operations. Name what each node, block, or reordered query state stores. If that claim cannot be maintained on a legal input, the pattern is wrong or one of its preconditions is missing. A counterexample is more useful than a vague warning: change one property of the sample, trace the first two steps, and identify the exact claim that fails.

Compare costs before committing. The advertised bound is O(log^2 n) path query · O(n) space; identify the operation responsible for it and the extra memory it needs.