Cool! I suspect there will be some incompatibilities with #1413 (which has been under review since forever), and #1805 (for the cgal::assign file). Would be great to get those sorted first.

Great points, Jeremie! I believe this should be compatible with #1413 , when @qnzhou and I do the test, we should start with that one, then re-run this PR.

Re our favorite #1805 , Daniele and I discussed a strategy for moving ahead this morning. We'll be in touch shortly. In terms of compatibility, I hope this PR is just bumping the commit hash, so easy merge but should be tested of course.

Update:

CGAL v5.4 has been officially released.

I've re-run the PWN subset of Thingi10k "self-union" stress test for the booleans. So far, 8595 out of 8621 have finished (a few take 10+ hours 🤯 ). All looks good in the sense of exactly matching rational output of the previous code. I'm content declaring success here (I'll try to squeeze out the last few models).

I'd also like to test the success rate of the float conversion. This was never guaranteed and the heuristic we used in the paper was never implemented fully in C++ anyway. In any case, I'd like to get a sense of whether we significantly more often get poor snap rounding results with the new code.

I'm nearly ready to declare success on this. I've run self-unions all 8620 valid PWN models from thingi10k. The new code produces exact (as in CGAL::Epeck) results that are the same (w.r.t. exactly equivalent triangles).

The new code also introduces new, faster rounding. Of these 8620 exact outputs, I first detect any self-intersections in the exact representations. After the #2019 fix, the new and old code agree there are no intersections. Then I convert to double (via assign) and check for intersections. Here we expect that some models have intersections. We could be worried that the new code has significantly more intersections after rounding to double. This is happily not the case. There are 109 (edit: still computing these, there may be a few more coming) out of 8620 models which produce intersections-after-rounding in either the new or old code. Of those, 29% have no intersections in the old code but ≥1 intersections in the new code. Conversely, 18% have no intersections in the new code but ≥1 intersections in the old code. In this sense, the old code is better, but I think it's roughly random. For 50% of the 109, the new code has more intersections than the old code. Putting in the larger context of the 8620 models, this means for only 0.006% would the new code output more intersections-after-rounding than the old code. And similarly, the old code would only 0.006% of the time output more intersections-after-rounding than the new code. My conclusion is that it's a wash and we should take the newer, simpler, faster rounding (the old code is still there behind a flag).

I've put my scripts for the batch jobs at https://github.com/alecjacobson/thingi10k-bool-test , we can also use this test and merge #1413.