Fix overflow edge case in sequence of balls volume method

[dymil]

Force rnum>=1, avoiding integer overflow when rnum-1 is passed into RandomPointGenerator::apply a few lines later, which hoovers up RAM and time. This edge case can be observed with a degenerate polytope (I tried a 1D interval) or with extreme choices of error and n_threads.

[codecov]

Codecov Report

Merging #228 (5b29181) into develop (59cd27e) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop     #228   +/-   ##
========================================
  Coverage    55.24%   55.24%           
========================================
  Files           85       85           
  Lines         4802     4802           
  Branches      2108     2109    +1     
========================================
  Hits          2653     2653           
  Misses         896      896           
  Partials      1253     1253           

Impacted Files	Coverage Δ
include/volume/volume_sequence_of_balls.hpp	66.66% <100.00%> (ø)

[vissarion]

Thanks @dymil for this PR! I am OK with merging of this change but please add the edge cases you mention in the test suite (this will eventually increase the coverage, notice that the CI is complaining about coverage decrease).

[vissarion]

You can add tests here https://github.com/GeomScale/volesti/blob/develop/test/volume_sob_hpolytope.cpp for (sequence of balls volume algorithm)

[dymil]

I added a 1D test case which fails (times out) with the old code but passes with the updated (after tweaking the fix to ensure rnum>=2 instead of 1). I also tried a 2D test case with large error or n_threads and those indeed trigger the overflow but, even with the fix, balls would be empty or something else would go wrong with a small rnum. The fix presumably needs to scale with dimension but I'm not sure exactly how, and, in any case, I find failing an assertion superior to simply hanging.

Alternative fixes which might be more suitable include shrinking n_threads if needed (rnum may still need to be increased if it was already small) or to make an earlier assertion so that the caller is better informed of the ultimate cause of the issue, rather than silently plugging the issue.