Correctness of max_inscribed_ball is unverified on polytopes with known analytical solutions

[Akash504-ai]

Describe the bug
The correctness of max_inscribed_ball is currently not verified by tests on polytopes with known analytical inscribed-ball solutions (e.g., axis-aligned boxes, simple simplices, low-dimensional cases). As a result, the algorithm may return numerically plausible but incorrect centers or radii without detection.

To Reproduce
Run max_inscribed_ball on simple polytopes with known inscribed ball properties (e.g., unit box, low-dimensional polytopes). There are currently no tests that validate the returned center and radius against expected analytical values.

Expected behavior
For polytopes with known inscribed ball solutions, max_inscribed_ball should return a center and radius that satisfy the constraints and match the expected analytical result within tolerance, and this behavior should be covered by regression tests.

Additional context
max_inscribed_ball is a foundational preprocessing routine used for feasibility detection, rounding, and sampling initialization. Its correctness currently relies on assumptions (e.g., normalized constraints, numerical scaling) that are not exercised or validated by tests. Adding targeted, non-invasive tests would help prevent silent correctness regressions and clarify intended behavior without changing the algorithm.

[vissarion]

Hi, thanks for opening this issue and for your interest in volesti. This looks more like a discussion than a bug. I transfer it to discussions.

[saksham-stack]

hey @Akash504-ai, i looked into this issue and found out that constraints aren't normalized before passing them to the solver. If $|a_i|_2 \neq 1$, and the algorithm assumes they are, the radius will be scaled incorrectly.
so, according you should a test fille using Boost.Test "test_geometry.cpp".
Hope this helps you.

[Akash504-ai]

Thanks for looking into this. Good catch on the constraint normalization that aligns with the concern about silently incorrect radii. I agree that adding a Boost.Test case using polytopes will help surface this assumption explicitly without changing the algorithm. In my openion, this would also clarify whether normalization is expected as a precondition or should be enforced internally