Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Changing std::rand() to a better inbuilt PRNG generator. #3239

Merged
merged 4 commits into from Mar 29, 2018
Merged

Changing std::rand() to a better inbuilt PRNG generator. #3239

merged 4 commits into from Mar 29, 2018

Conversation

Anushi1998
Copy link
Contributor

Fixes #2954
This PR is in continuation of PR #3204.

@hkaiser hkaiser added this to the 1.1.0 milestone Mar 13, 2018
@msimberg
Copy link
Contributor

@Anushi1998 it looks like some tests are now failing. If you click on pycicle daint-3239... details and then the red 3 under Test/Fail you can see which ones failed. In this case it might be that the range of std::rand and your new generator are not the same so you might need to do some adjustments to make the tests happy again.

@Anushi1998
Copy link
Contributor Author

@msimberg
The test failing on files have all in common
std::iota(std::begin(c), middle, gen()); i.e gen() is used only in std::iota
Can you help me with why this is failing here and why not in the previous PR?
There are files(in previous PR) tests/performance/local/foreach_scaling.cpp like this which had used std::iota

@msimberg
Copy link
Contributor

msimberg commented Mar 15, 2018 •
edited

Looking at one of the tests the problem seems to be that std::rand returns numbers between 0 and RAND_MAX, whereas the generator can return any int and these tests expect the numbers to be non-negative. So you would need to restrict the range using a distribution.

You should also restrict the range of the distribution to make sure that the elements don't wrap around to negative numbers when using std::iota (check the documentation).

Let me know if something is unclear!

@Anushi1998
Copy link
Contributor Author

Anushi1998 commented Mar 15, 2018 •
edited

@msimberg gen() is giving random number in range [0,gen.max()] and gen.max() is given by (2^w-1) where w is word length.I thought that it is not exceeding INT_MAX (since we also have mt19937_64)(so I tried uniform_int_distribution<>(0,gen.max()-100007)) but I just checked that it(gen.max()) was actually overflowing Integer!(gen.max() is actually UINT_MAX)
So I better will make the upper limit to INT_MAX!
Thanks for the help :)

@msimberg
Copy link
Contributor

Oh, even better. Thanks for correcting me! You seem to have gotten the hang of it. You might also find std::numeric_limits useful (instead of INT_MAX).

@Anushi1998
Copy link
Contributor Author

Yeah, Sure! I was actually checking for any way to pass w in mt19937 constructor but unfortunately I haven't till now! I will better use std::uniform_int_distribution.

hkaiser
hkaiser reviewed Mar 15, 2018
View reviewed changes
tests/unit/parallel/algorithms/copyif_random.cpp Outdated
@@ -21,7 +23,7 @@
////////////////////////////////////////////////////////////////////////////
unsigned int seed = std::random_device{}();
std::mt19937 gen(seed);
std::uniform_int_distribution<> dis(0,std::numeric_limits<int>::max());
std::uniform_int_distribution<> dis(0,boost::integer_traits<int>::max());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you go away from std::numeric_limits?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because Circle CI was failing violation of Boost min/max guidelines.Should I do something else?

Copy link
Member

@hkaiser hkaiser Mar 15, 2018 •
edited

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yah, sure. If you look around you'll find this: http://www.boost.org/doc/libs/1_34_0/more/lib_guide.htm (amongst other things). Essentially the Boost guidelines say that in order to avoid min or max being expanded as a macro you need to accordingly protect all of their uses. In case of std::numeric_limits<T>::max() you would have to write (std::numeric_limits<T>::max)() instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for correcting me :)
I will fix it right away.

@Anushi1998
Copy link
Contributor Author

Anushi1998 commented Mar 16, 2018 •
edited

@hkaiser I think the pycicle daint-3239-gcc-6.2.0 Test is unrelated because I haven't changed those 3 files.It can be removed probably by restarting tests.What's your opinion?

@msimberg
Copy link
Contributor

@Anushi1998, yeah, those are unrelated to your changes.

@Anushi1998
Copy link
Contributor Author

@msimberg @hkaiser Please review this PR and let me know if I missed something :)

hkaiser
hkaiser approved these changes Mar 19, 2018
View reviewed changes
Copy link
Member

@hkaiser hkaiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@msimberg msimberg modified the milestones: 1.1.0, 1.2.0 Mar 22, 2018
@msimberg
Copy link
Contributor

Thanks @Anushi1998!

@msimberg msimberg merged commit f72a61c into STEllAR-GROUP:master Mar 29, 2018
@Anushi1998 Anushi1998 mentioned this pull request Apr 27, 2018
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hkaiser hkaiser hkaiser approved these changes

Assignees
No one assigned
Labels
category: tests type: compatibility issue type: enhancement
Projects
None yet
Milestone
1.2.0
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@Anushi1998 @msimberg @hkaiser