Evaluate Division
Recognize the pattern
Brute force idea
A straightforward first read of Evaluate Division is this: For each query, try all paths — potentially exponential without visited tracking. That instinct is useful because it follows the prompt literally, but it usually keeps revisiting work the problem is begging you to organize.
Better approach
A calmer way to see Evaluate Division is this: Build a weighted directed graph: a/b = v means edge a→b with weight v and b→a with weight 1/v. For each query, BFS/DFS from start to end, multiplying weights along the path. The goal is not to be clever for its own sake, but to remember the one relationship that keeps the solution grounded as you move forward.
Key invariant
The truth you want to protect throughout Evaluate Division is this: If a/b = 2 and b/c = 3, then a/c = 6. The path from a to c in the graph gives the product of edge weights, which is the division result. No path means undefined (-1). If that remains true after every update, the rest of the reasoning has a stable place to stand.
Watch out for
The trap in Evaluate Division usually looks like this: Not adding the reverse edge — if a/b = 2, then b/a = 0.5. Both directions must be in the graph. When the code becomes mechanical before the idea is clear, small edge cases start breaking the whole story.