For an iterative gradient evasion attack driven from an adversarial-robustness library such as the Adversarial Robustness Toolbox or torchattacks, what does raising each of these three arguments buy you — the iteration count, the step size relative to the perturbation bound, and the number of random restarts — and what does each cost?

### The loop these three arguments drive An iterative gradient evasion attack is a short optimisation loop: start somewhere inside the region the perturbation bound allows around an input, compute the gradient of a loss with respect to that input, take a step along it, project back inside the region, repeat. The three arguments in the question are the only handles you have on that loop. Each one closes off a distinct way the loop can fail for a reason that has nothing to do with the model — which matters because the library reports a failed optimisation and a genuinely hard target identically, as "no adversarial example found". ### Iterations — refinement `max_iter` in the Adversarial Robustness Toolbox's `ProjectedGradientDescent`, `steps` in `torchattacks.PGD` and in `foolbox.attacks.LinfPGD`. More iterations mean more, smaller corrections, so the search can settle at the edge of the allowed region instead of stopping wherever the budget ran out. The tell that you have too few is direct: double the count and watch whether the attack-success rate is still climbing. Cost is linear in the count. ### Step size — coupled to the bound, never independent `eps_step` in ART, `alpha` in torchattacks, `rel_stepsize` in Foolbox. This is not a strength knob on its own; it is only meaningful relative to the bound and the iteration count. The product of step and iterations has to be able to traverse the region epsilon defines, and the step has to be fine enough to settle inside it rather than bouncing off the projection on every pass. The libraries genuinely differ here, and the difference is where the silent misconfiguration lives: | library | how the step is expressed | what happens when you tighten epsilon | |---|---|---| | Foolbox `LinfPGD` | `rel_stepsize`, a fraction of the epsilon passed at attack time | the step shrinks with the bound automatically | | ART `ProjectedGradientDescent` | `eps_step`, an absolute value | the step stays put and is now coarse relative to the smaller `eps` | | torchattacks `PGD` | `alpha`, an absolute value | same as ART — it does not follow `eps` | Tighten epsilon for a stricter threat model in ART or torchattacks, leave the step alone, and every iteration now overshoots the region and is projected straight back. The model looks more robust, and the entire gain is configurational. ### Restarts — independence from where you began `num_random_init` in ART, `random_start` in torchattacks and Foolbox (with the run repeated to get several draws). Each restart is an independent draw of a starting point inside the allowed region. On an uneven loss surface some starts find a descent direction and some sit in a flat patch and go nowhere; with one start you have sampled that lottery once and reported the outcome as a property of the weights. ART's `num_random_init` defaults to zero, so an ART defaults run is a single deterministic start. Restarts are also the most expensive knob, because they multiply the whole loop rather than lengthening it. ### What it costs Model calls are roughly `examples × restarts × iterations`, each a forward and a backward pass. A thousand examples at a hundred iterations with five restarts is half a million forward-backward passes — tens of minutes to hours on one modern GPU at CIFAR scale, GPU-days at ImageNet scale with a large backbone, low single-digit dollars per GPU-hour on rented capacity. Doubling all three at once is an eight-fold budget request, which is exactly why nobody should raise them blindly. ### Where the number misleads The dangerous reading is a low attack-success rate quoted as robustness when the success-versus-effort curve was still climbing at the configuration used. That number is a statement about your compute budget wearing the clothes of a statement about the model. The second misreading is treating restarts as noise reduction: they are not averaging away variance in a measurement, they are additional independent attempts, and omitting them does not make the estimate noisier, it makes it *biased low*. The third is subtler. If you spend a fixed budget on many examples at default effort, you get a tight confidence interval — around the wrong quantity. Precision on a weak attack is not accuracy about the model. ### What you would check Run a small effort sweep on a subset before the headline run: a handful of `(iterations, restarts)` pairs, each roughly doubling the previous, plotted against attack-success rate. The point where the rate stops moving materially is your assessment configuration. Everything above it is wasted budget; everything below it is an under-strength result. Then, when budget binds, cut the number of examples rather than the effort — and if you changed the bound at any point, re-derive the step size for the new epsilon rather than inheriting the old one.