Update rand with C++11 random generators in tests module

[shrijitsingh99]

Solves rand uses in tests module as mentioned in #3781
Modules left in tests:

• common
• filters
• io
• kdtree
• outofcore
• registration
• sample_consensus
• search
• segmentation

[shrijitsingh99]

@kunaltyagi Before I go ahead and implement this for the remaining modules. Is the any problem or changes needed in the current implementation?

[SergioRAgostinho]

Word of advice for this PR: split changes which make unit test fail into isolated PRs. They usually involve a lot of discussion and considerable changes on their own.

[shrijitsingh99]

Word of advice for this PR: split changes which make unit test fail into isolated PRs. They usually involve a lot of discussion and considerable changes on their own.

So do you mean split into separate PR's based on modules?

[SergioRAgostinho]

Not necessarily. Make all the changes that you can, which do not require you to touch the unit tests. We merge those first. Then we open a PR for each change which requires modifying the unit tests, because those tend to be noisy PRs. They usually involve digging around the reason the unit test is failing, occasionally rewriting unit tests from scratch to actually do sane testing.

As an example have a look at how I split the commits for the following PR #3862. I made all the changes I could until the point I knew it would break the unit tests. The followup commits are to address the broken unit test. Everything is in a single PR because I was only touching a single class.

[kunaltyagi]

Rebase and push to trigger another CI run. As per Ubuntu, there seems to be no issues, but let's see with the latest master once again

The API seems awkward, but that's upto another PR to make it better (or replace/remove it) (discussion issue created)

Usage is correct and I'd recommend moving forwards, specially with the cloud generators. The API update seems the only reason I'd consider for not moving ahead.

[shrijitsingh99]

Not necessarily. Make all the changes that you can, which do not require you to touch the unit tests. We merge those first. Then we open a PR for each change which requires modifying the unit tests, because those tend to be noisy PRs. They usually involve digging around the reason the unit test is failing, occasionally rewriting unit tests from scratch to actually do sane testing.

Got it thanks 👍 . Will keep this in mind in the future and will modify this PR accordingly.

Rebase and push to trigger another CI run. As per Ubuntu, there seems to be no issues, but let's see with the latest master once again

Done

Usage is correct and I'd recommend moving forwards, specially with the cloud generators. The API update seems the only reason I'd consider for not moving ahead.

Yeah will defer this until API update no point doing a refactor again if there is some major API change and making some modifications to the API will definitely make it cleaner.

[stale]

Marking this as stale due to 30 days of inactivity. Commenting or adding a new commit to the pull request will revert this.

[shrijitsingh99]

Closing this will pick it up again once we have the new random interface as being discussed #3996