[Point Set Processing] Big factorization + cleanup#4552
[Point Set Processing] Big factorization + cleanup#4552sloriot merged 32 commits intoCGAL:masterfrom
Conversation
… of factorized KD Tree
|
still :( |
|
Sorry, I should have spotted those… I rerun PSP examples + tests locally, it should be good now. |
|
A license issue, now: https://travis-ci.com/CGAL/cgal/jobs/294843121#L2868 |
|
Please do not merge this PR yet, I just found a bug. |
|
Fixed. |
|
There is a least one warning. Please check other possible impacted packages. Poisson runtime error is most probably related to the PR about the compact container. |
| return m_random.get_double() < ratio; | ||
| bool operator()(Iterator it) const { | ||
| // make the result deterministic for each iterator | ||
| return Random((std::size_t)(&*it)).get_double() < ratio; |
There was a problem hiding this comment.
@lrineau : this is not something we should do, right?
@sgiraudot what are you trying to achieve? you need different seeds per iterator? This won't be deterministic across runs AFAIU.
There was a problem hiding this comment.
First, that does not seem efficient, to create an object of type Random, at each call, just to get a few random bits.
Second, I am surprised, because I think the previous version (before the patch) seemed deterministic, and then the second one seems to be non-deterministic, because that depends on the memory layout. And the comment says the contrary.
There was a problem hiding this comment.
The previous version produced a different range everytime a for() loop was used to iterator from begin to end, which created problems in the new version of compute_average_spacing() where the range is iterated twice. This patch was made to make the range consistently the same if iterated several times.
There was a problem hiding this comment.
can't you init the random with the size of the range as seed once?
There was a problem hiding this comment.
It's not a matter of initialization.
Do this:
for(const auto& : range)
// something
for(const auto& : range)
// somethingand you don't get the same range on the second loop, no matter the initialization. Maybe I could use a trick to initialize a shared Random object when calling begin()…
|
The following files have trailing whitespaces: |
|
Tested in CGAL-5.1-Ic-114 |
Summary of Changes
This PR introduces many factorizations and cleaning in the PSP package (internal code only, no API change):
Parallel_callbackI introduced to handle callbacks in parallel mode is replaced by aCallback_wrapperwhich indifferently works with sequential and parallelCGAL::for_eachis introduced to run a functor on a range either sequentially or in parallel with TBB. It checks that no parallel tag is used without TBB being linked and it handles the cases of parallel loop on non-random access iterators (by copying iterators in a vector, which is equivalent to what was done in PSP in general, only now it only happens in the worst case scenario)In general, the code of PSP is largely reduced and much more readable. Many functions were written ike that:
Now they look like that:
CGAL::for_each<ConcurrencyTag> (points, [&](const typename PointRange::const_iterator::value_type& t) { /* The actual algorithm */ });Release Management