Uniform RDHR walk can silently stagnate due to missing validation of line–polytope intersection

[Akash504-ai]

Describe the bug
The Uniform Random Direction Hit-and-Run (RDHR) implementation assumes that the line–polytope intersection along a sampled direction always produces a non-degenerate feasible segment.
However, this assumption is not validated.
In edge cases (e.g., low-dimensional or nearly degenerate polytopes, or directions almost orthogonal to the feasible region), the intersection interval can collapse to near-zero length. In such cases, the sampled step size becomes ineffective and the Markov chain fails to move, leading to silent stagnation.
This does not trigger a runtime error or warning, but results in a non-mixing chain and incorrect sampling behavior.

To Reproduce

1. Use uniform_rdhr_walk.hpp with a low-dimensional (1D/2D) or thin polytope
2. Sample a random direction that produces a nearly zero-length feasible intersection
3. Observe that:
   - (bpair.first - bpair.second) ≈ 0
   - the sampled _lambda collapses
   - the current point remains unchanged
4. Repeat over multiple steps and observe that the chain does not evolve
   The issue can occur both during initialization and during subsequent apply() steps.

Expected behavior
The RDHR walk should either:

• validate that the feasible intersection interval has positive length, or
• resample the direction when the interval is degenerate, or
• emit a diagnostic warning when no effective movement occurs.

The Markov chain should not silently stagnate under valid (but edge-case) inputs.

Actual behavior

• No validation of the intersection interval length
• No fallback or retry logic when the interval collapses
• No warning or assertion when the chain does not move
• The walk proceeds while producing identical (or nearly identical) samples

Additional context
Relevant code locations:

include/random_walks/uniform_rdhr_walk.hpp

• No checks on the result of line_intersect(...)
• Assumes bpair.first > bpair.second
• Same issue appears in both initialization and apply()

This failure mode is similar to other silent stagnation issues observed in random-walk implementations and can significantly affect sampling correctness without being detected.

[vissarion]

Hi, thanks for opening this issue and for your interest in volesti. This looks more like a discussion than a bug. I am closing it as a "not a bug".
Please feel free to reopen it with a concrete code example that describes the bug.