Brute force over fifty items is out of reach even for a computer, so the certificate comes from a second live computation instead: this book's own dynamic-programming table, run on the same instance, which reaches the same optimal value as the solver.
highlighted = computed this step
Why not brute force
Checking every subset of fifty items means checking two to the fiftieth power candidates, 1125899906842624. Why: unlike the assignment book's 120 permutations or the bin-packing book's 678570 set partitions, both small enough to enumerate exactly, that count is genuinely out of reach — this is the one instance in the track where enumeration is not an option at all, not even as a slow extra check.
250=1125899906842624
This book's own DP agrees
This book's own dynamic-programming table, run on the same fifty items and the same capacity, reaches the identical optimal value. Why: dynamic programming is pseudo-polynomial — its cost depends on item count times capacity, not on the number of subsets — so it stays exact and fast here even though brute force cannot run at all.
DP optimum=7534=solver objective
The selections happen to coincide
On this instance the solver's chosen items and the DP's traceback are the identical set. Why: that agreement is not the certificate and is not guaranteed in general — knapsack can have several optimal subsets at the same value; the certificate is the two independent computations landing on the same value, 7534.
same value, and here the same set
The selection fits exactly
The chosen items weigh exactly 850, filling the capacity of 850 with nothing left over. Why: this is a property of this pinned instance, re-verified with this book's own arithmetic on the decoded selection, not an assumption the atom takes on faith.
850=850
Diagram note
The highlighted cells are the same decoded selection as the previous lesson; the caption's optimum is recomputed from this book's own DP on every build, not a copied number. Pixel positions are rounded for layout; every number shown is exact.