Section 17.6 leaves you with a test, not a recipe. The conditions and remove schedules that cannot work, but they do not say which of the survivors is fastest. The constants in the convergence bounds are unknown in practice, and the section says batch size is settled by what the hardware does well rather than by a theorem about accuracy. Section 17.5 adds the reason: a constant step settles at a noise floor whose size moves with the step and the batch, and the two knobs trade against each other.
You have a fixed compute budget and a new model, and you must choose the step schedule , the batch size , and the number of steps. Design a protocol for making those choices and for reporting the result. In your answer: say what you measure during the run and what you compute from the measurements; say what your protocol promises and over what range of runs; state what result would make you change the schedule; and name one way the protocol can mislead you even when every step is followed.
Rubric. Tick each criterion your answer meets, then save the self-assessment. The platform does not grade it.
Worked solution
There is no single correct answer, so this is a model of the shape a complete answer takes, not a key. A level-3 answer begins by stating the budget as a product: work per step times number of steps. It fixes a batch that the hardware handles well, because section 17.6 says the batch is not where the theorem decides, and it reserves the schedule for the accuracy target. It picks a schedule that passes both tests, such as with a short constant warm-up, and it records the loss on held-out examples at checkpoints spread across the run.
From those checkpoints the answer estimates two things: the rate at which the held-out loss falls, and the size of the fluctuations around the fall. The fluctuations estimate the noise floor, and the floor tells the reader whether more steps at this step size can help. If the floor is above the target, the answer shrinks the step or grows the batch; if the fall has stalled while the floor is below the target, it changes the schedule rather than spending more steps. The answer states that both changes cost: growing the batch multiplies the work per step, and shrinking the step slows the contraction by the factor in section 17.4, so the budget must be re-divided rather than added to.
The report separates the final value from the noise around it. It quotes the held-out loss with a spread from the last few checkpoints, and it says the promise holds for the sampling model and the data distribution it measured, not for a new distribution. It gives the search cost: every schedule tried on the same budget consumes runs that could have been spent on the final one, so the reported result is optimistically selected unless a final run is held back. It names a failure: a schedule tuned on a short run can pass both tests and still be far too slow, and the short run will not show the floor because the step is still large. The answer that scores 0 says only that the step should shrink and stops there.