DP

Start by clarifying the exact contract for Dynamic Programming: input representation, mutation rules, duplicate behavior, and what should happen on invalid or empty input. The core idea is state semantics and dependency-respecting evaluation order. Work a tiny example aloud and name the invariant after each step, because that is the proof that the approach stays correct as the input grows.

A dependable implementation plan is to derive overlapping subproblems; define smallest sufficient state; write transitions and base cases; choose top-down or bottom-up; count states times transitions. A DP table without a state definition is not an explanation. Keep the code aligned with that invariant instead of adding special cases that silently change the contract. Test the smallest input, a normal case, duplicates or ties where relevant, an adversarial boundary, and a case that exercises the failure path. The expected complexity is time is states times transitions; memory is retained states. Explain both time and auxiliary memory, including recursion or helper structures; do not hide sorting, copying, or repeated scans. If the title omits critical constraints, say what you need to know before committing to a more specialized solution.

Complexity: If the confirmed DP has n states and a transitions per state, its bound is O(na) time and O(n) space before any rolling-array optimization.