The DP table behind this instance has tens of thousands of cells, too many to draw. This chapter shows the value and the selection the table certifies instead, and states plainly what it does not claim about larger capacities.
highlighted = computed this step
The table itself is too large to show
The full DP table has 43401 cells. Why: it is one row per item prefix and one column per capacity value, the same table chapter two fills by hand at four rows and eight columns — the algorithm scales cleanly to this size, but a grid this large stops being a useful picture even though every cell in it is still exact.
(50+1)×(850+1)=43401
Show the answer, not the table
This chapter shows the selected items and the optimal value instead of the table that produced them. Why: the earlier chapters exist to show how the table thinks; once the table is too big to look at, what still transfers is the value and the selection it certifies, not the grid.
answer shown; table computed, not drawn
Scope of the chapter
Nothing here replaces the earlier chapters: the DP method is still exact on an instance of this size, and the solver's role is providing an independent second computation, not a better answer. Why: dynamic programming's cost is pseudo-polynomial in the capacity number, so a much larger capacity would eventually make the table too slow to fill, not just too large to draw — this chapter makes no claim about where that happens.
exact here; no runtime promise at other capacities
Diagram note
The grid is the same fifty-item instance as the earlier lessons in this chapter. Pixel positions are rounded for layout; every number shown is exact.