Test set operations on random grids with integer coordinates

[tinko92]

As discussed in #1356 , this adds an overlay test from https://gist.github.com/tinko92/fad450e1058ce8ceebde66a6b86d45c1 that generates grids based on bit patterns and verifies the correctness of set operation by testing against the corresponding logical operation on the bit sets.

The test is cleaned up and generalized to take width and height options from the command line. It is not intended to be run by default as part of the test suite (I understand, this is not the case for the robustness tests in general?) because it is only useful with a large iteration count and thereby long-running. It is also meant to be built with optimizations to mitigate the high time cost and prints failures to stdout in WKT with the corresponding bitset rather than triggering assertions.

The design idea was to build a test that, in principle, could test every possible code path in overlay (for sufficiently large width and height). I lack the insight in the overlay details to judge whether it meets that goal. It is also meant to test only for non-numerical issues, so it intentionally only supports integer coordinates. The limitation to a rectangular grid is just for simplicity of implementation, but in principle every indexable, disjoint set of rings with corresponding test points should work.

[barendgehrels]

Cool! I'll review it Wednesday

[barendgehrels]

It is not intended to be run by default as part of the test suite (I understand, this is not the case for the robustness tests in general?) because it is only useful with a large iteration count and thereby long-running.

This is completely fine, indeed the robustness tests are to be executed manually. I do it regularly (not all of them, but some).

I'll continue tonight or tomorrow - I had some remarks but basically it looks good, I'm glad with the addition.

[tinko92]

The second commit was intentionally not squished to delineate the new changes from the already reviewed ones but I can rebase and force push if a single commit PR is prefered.

[barendgehrels]

The second commit was intentionally not squished to delineate the new changes from the already reviewed ones but I can rebase and force push if a single commit PR is prefered.

I usually look at compare so for me it's fine to squash it. But this is also fine.

[vissarion]

Thanks Tinko, LGTM.

[tinko92]

Thanks for the comments, @vissarion (I think some of the early ones maybe overlapped with my previous push) and @barendgehrels !

(Sorry about that 50c20ad push. I wasn't aware of that cmake test running on my private fork, or I would have run it locally to catch that before pushing).

[barendgehrels]

👍

[barendgehrels]

Can we merge this?

[tinko92]

Can we merge this?

I checked all conversations and resolved every point as addressed. Should I merge it or is that for someone with a boostorg member role to do?