Unintuitive is_in() semantics

[Akash504-ai]

Describe the issue
volume_cooling_balls.hpp relies on is_in() return values to count points inside various convex bodies. The code assumes that a return value of -1 indicates that a point lies inside the body.
However, different convex body implementations (HPolytope, Ball, BallIntersectPolytope, etc.) use different return conventions for is_in(), and recent changes updated the semantics for some bodies but not all.
This can lead to silent miscounting during ratio and convergence estimation, depending on the concrete convex body type used.

Impact
The issue does not cause crashes but may affect correctness of volume estimates due to inconsistent inside/outside classification.

Additional context
This is a semantic consistency issue rather than a localized bug, and resolving it likely requires either:

• clarifying and enforcing a uniform is_in() contract, or
• updating call sites to explicitly compare against documented semantics per convex body type.

[ChinmayRout9040895625]

Hi @Akash504-ai!
Thanks for the detailed report — I agree that this is a semantic consistency issue rather than a localized bug.

After reviewing volume_cooling_balls.hpp and the convex body implementations, the core problem appears to be that the volume routines implicitly assume a uniform is_in() contract (i.e. negative return values indicate points strictly inside the body), while different convex bodies currently use inconsistent return conventions. Recent changes updated the semantics for some bodies but not all, which can indeed lead to silent miscounting during ratio estimation and convergence checks.

I propose addressing this by enforcing a single, documented is_in() contract across all convex body implementations, namely:
(1) "is_in(x) < 0 → point is strictly inside"
(2) "is_in(x) == 0 → point lies on the boundary"
(3) "is_in(x) > 0 → point lies outside"

With this contract enforced at the geometry layer, volume algorithms such as volume_cooling_balls can remain generic and correct without introducing body-specific logic at call sites.

Concretely, this would involve auditing and normalizing is_in() implementations for all convex bodies (e.g. HPolytope, Ball, BallIntersectPolytope, etc.), updating any deviations to conform to the contract, and documenting the semantics explicitly to prevent future drift.
I’m happy to prepare a PR along these lines if this direction sounds reasonable.

[Akash504-ai]

Thanks @ChinmayRout9040895625 for the detailed analysis and for validating the issue, I agree with your assessment.
Enforcing a single, well-documented is_in() contract at the geometry layer (with negative values indicating strict interior, zero for boundary, and positive for exterior) does seem like the cleanest long-term solution, and it aligns with the assumptions currently made in volume_cooling_balls.hpp.
Since this change would affect multiple convex body implementations and their semantics, it would be good to get explicit maintainer confirmation on this direction before proceeding with a PR. Once the direction is confirmed, I’d be happy to help with auditing implementations or reviewing changes.

[Akash504-ai]

@TolisChal @vissarion
Could you please advise on the preferred way forward here?

Both @ChinmayRout9040895625 and I agree that enforcing a single, documented is_in() contract across convex bodies would be the cleanest solution, but since this would involve semantic changes at the geometry layer, we wanted to confirm that this direction is acceptable before preparing a PR.
Happy to help with implementation or review once the approach is confirmed.

[ChinmayRout9040895625]

Thanks @Akash504-ai for confirming - that sounds good to me.
Please let me know when it’s okay to proceed. Happy to proceed once the direction is formally approved.