-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
Provide cross-platform seed generation #3306
base: master
Are you sure you want to change the base?
Conversation
We shouldn't use In C++11 std::random_device may be implemented in terms of an implementation-defined pseudo-random number engine if a non-deterministic source (e.g. a hardware device) is not available to the implementation. In this case each std::random_device object may generate the same number sequence. In constrast, Boost specifies that for those environments where a non-deterministic random number generator is not available, class random_device must not be implemented. |
@bhack although I am interested (and was aware of #2537), I feel that this (removing boost) may be premature. Additionally, the problem at hand (seed generation) inspires caution: C++ 11 isn't always an ideal replacement for Boost. |
The effort started to minimize the dependencies for mobile and embedded (specially for forward pass only of trained nets). I.e. in android boost it is not so much a first grade citizen. See #2619 |
I repeat again. Are we sure that we are not embracing a rearguard position? |
@bhack currently caffe builds default to C++98. As mentioned before I'm looking into a workaround so that we can be more inclusive. |
Ready for review/merge. |
@ronghanghu can you guys have a look at this? |
Previously (#842), the use of an entropy source was added so that caffe's RNG uses a random seed by default. Although @netheril96 suggested that we avoid
boost::random_device
, I contend that incurring a dependency on boost random is a small price to pay for cross-platform compatibility.Additionally, is there a practical reason to preserve the fallback solution via
getpid
?