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.

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

Bug: Compile-time and runtime-polymorphism do not work together #65

Open
hsloot opened this issue Sep 20, 2023 · 1 comment
Open

Bug: Compile-time and runtime-polymorphism do not work together #65

hsloot opened this issue Sep 20, 2023 · 1 comment

Comments

@hsloot
Copy link
Contributor

hsloot commented Sep 20, 2023

Problem

Some of boost's internal functions are fully specialized for dqrng::random_64bit_generator; see below. However, this specialization works for dqrng::random_64bit_generator only and not for any of its derived classes. See also https://stackoverflow.com/a/27988380.

namespace boost {
namespace random {
namespace detail {
template<>
inline std::pair<double, int> generate_int_float_pair<double, 8, dqrng::random_64bit_generator>(dqrng::random_64bit_generator& eng)
{
dqrng::random_64bit_generator::result_type x = eng();
double r = dqrng::uniform01(x);
// shift x due to weakness of lowest bits for xoshiro/xoroshiro with used "+" scrambler
int bucket = (x >> 3) & 0xFF;
return std::make_pair(r, bucket);
}
template<>
inline double generate_uniform_real<dqrng::random_64bit_generator, double>(dqrng::random_64bit_generator& eng, double min, double max)
{
return dqrng::uniform01(eng()) * (max - min) + min;
}
} // namespace detail
} // namespace random
} // namespace boost

Possible solutions

I do not know if there is a natural fix as the original template definitions are part of the boost headers. Other than that, either all derived classes of dqrng::random_64bit_generator should have the same specialization or only dereferenced pointer-to-dqrng::random_64bit_generator should be passed into any distribution.

@rstub
Copy link
Member

rstub commented Sep 21, 2023

For now it looks like adding the same specialization is the way to go. In addition, I should also investigate to what extend these specialization are actually needed, i.e. if they still give a performance advantage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants