Problem

Volesti’s random walk implementations handle different failure internally (for example, bounded reflection loops, invalid intersections, or skipped steps) but they do not expose any clear signal about whether the walk actually made progress or failed.
Because of this, users and downstream algorithms cannot tell the difference between successful sampling and cases where the walk silently gets stuck or becomes numerically degenerate. Although diagnostics tools exist in the codebase, they are separate from the random walk logic and do not signal problems during the walk.

Minimal reproducible scenario (conceptual)

• Take a low-dimensional, nearly degenerate, or ill-conditioned polytope.
• Run a random walk such as uniform_billiard_walk or shake_and_bake_walk for a fixed number of steps.
• Internally, the walk may:
  • reach a maximum number of reflections,
  • skip steps due to invalid intersections or
  • stay at the same point.
• Even in these cases, the walk returns a point without indicating that no meaningful movement happened.

From the users point of view this looks the same as successful sampling.

What this change would fix

This issue aims to make random walks explicitly report whether they made progress or got stuck or maybe encountered a failure. This would allow users and downstream algorithms to distinguish valid sampling from silent failure cases.

Impact

Without clear walk-status information:

• sampling failures are hard to debug
• silent stagnation can go unnoticed and
• algorithms that rely on these samples may produce unreliable results.

Validation / non-regression expectations

Any solution should:

• keep the current behavior for walks that work normally,
• not introduce noticeable performance slowdowns, and
• be testable with small examples where the walk does not move or stagnates.