-
Notifications
You must be signed in to change notification settings - Fork 549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/speedup random sampling filter #396
Feature/speedup random sampling filter #396
Conversation
Can one of the admins verify this patch? |
add to whitelist |
The build is failing. Do you know what might be the reason? |
It's the macos built that failed: /Users/macmini-admin/workspace/pointmatcher/label/osx/pointmatcher/DataPointsFilters/RandomSampling.cpp:91:14: error: no type named 'Index' in namespace 'Eigen'
for (Eigen::Index i = 0; i < nbPointsIn && j<=nbPointsOut; i++)
~~~~~~~^
1 error generated.
make[2]: *** [CMakeFiles/pointmatcher.dir/pointmatcher/DataPointsFilters/RandomSampling.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
2 warnings generated.
make[1]: *** [CMakeFiles/pointmatcher.dir/all] Error 2
make: *** [all] Error 2 |
Sorry for the wait, I had switched to other tasks at work. I modified the file I added a buffer for the random numbers given by the original method, and plotted them: This is what we get when we use the 'Direct RNG' sampling method: And this is what we get when we enforce uniform sampling: All methods seem to give equivalent results (at least visually). I also checked how we can test for the uniformity of a distribution, there's a method from scikit, but I'll wait for input on whether we should test that first. |
Looking good! |
most probably the same compilation error |
I'll rebase berfore we can merge, to keep the history short. |
In order to resolve issue #393 I worked on speeding up the RandomSamplingDatapointsFilter. For that I implemented two random sampling methods:
I chose to sample directly a set of floats instead of templating that type. The reason being that float arithmetic should be enough, in my view, to achieve the goal of the filter. Double precision numbers might introduce an overhead.
I refactored a bit the existing unit testing code and ran it locally.
Last but not least, I tried to use the new std::random library, as recommended here. Related talk.
I'm submitting this PR for early feedback. Nonetheless, I still plan to run and plot the samples to get a grasp on the quality of the sampling process, as requested by @pomerlef in the related issue 🙂