Minimum Sum of Products of Two Arrays is a clean greedy problem. Given two arrays of equal length, you may reorder each one freely, then you sum the products of matching positions. The goal: make that sum as small as possible.
Problem. Given two integer arrays a and b of the same length n, you can reorder the elements of
each array however you like. After reordering, the cost is the sum of element-wise products
a[0]*b[0] + a[1]*b[1] + ... + a[n-1]*b[n-1]. Return the minimum possible cost.
Example: a = [5, 3, 1], b = [2, 4, 6] → minimum 28 (pair 1*6 + 3*4 + 5*2 = 6 + 12 + 10 = 28).
The slow way first
The brute-force idea: try every possible pairing of a against b. With n elements there are n! permutations of one array against the other — for n = 10 that is already over three million arrangements. Computing the sum for each is hopelessly slow. We need a rule that picks the best pairing directly.
The question to ask: which value should the largest element of one array meet? Intuitively, a large value hurts the total most, so it should be multiplied by the smallest available partner to keep the product down.
The idea: big meets small
Sort a ascending and b descending. Now the smallest element of a lines up with the largest of b, and the largest of a lines up with the smallest of b. Sum the element-wise products. This "rearrangement" pairing always gives the minimum.
This is the rearrangement inequality: a sum of paired products is smallest when one sequence is sorted opposite to the other. We do not have to prove it from scratch in an interview, but knowing the name signals you understand why the greedy choice is correct.
Walk through it
Step through the animation. First both rows snap into sorted order — a increasing, b decreasing. Then we pair column by column: 1×6, 3×4, 5×2, accumulating the running total. After the last pair the total is 28, the minimum possible.
Pseudocode
sort a in ascending order
sort b in descending order
total = 0
for i from 0 to n-1:
total = total + a[i] * b[i] # big paired with small
return totalThe Python solution
def min_sum_product(a, b):
a.sort()
b.sort(reverse=True)
total = 0
for x, y in zip(a, b):
total += x * y
return totala.sort()putsain ascending order.b.sort(reverse=True)putsbin descending order — the opposite direction.zip(a, b)walks both sorted arrays in lockstep, handing back matching pairs.- Each iteration adds one product
x * ytototal. Because the arrays are sorted oppositely, every large value is multiplied by a small one. - We return
total, which is provably the minimum over all reorderings.
Complexity
| Case | Time | Notes |
|---|---|---|
| Brute force (every pairing) | O(n!) (slow) | try all permutations |
| Greedy (this solution) | O(n log n) (moderate) | dominated by the two sorts |
O(1) (fast)The work is two sorts, each O(n log n), followed by a single O(n) pass to sum the products. Sorting in place uses no extra space beyond the arrays themselves.
When this pattern shows up
When a problem lets you reorder two sequences and asks to minimize or maximize a sum of paired products, reach for the rearrangement inequality: sort them in the same direction to maximize, in opposite directions to minimize. The greedy "pair extremes against each other" move appears in many scheduling and assignment problems.
Direction matters. To minimize you sort the two arrays oppositely; to maximize you sort them the same way. Mixing this up flips your answer to the worst case instead of the best.
Practice
For a = [1, 3, 5] sorted up and b = [6, 4, 2] sorted down, what does index 2 contribute to the total?
1. To minimize the sum of element-wise products, how should the two arrays be sorted?
2. What is the overall time complexity of the greedy solution?
3. Which principle guarantees that opposite sorting gives the minimum?
4. If you instead wanted the MAXIMUM sum of products, what would change?