You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment I am using distribution functions from boost.random and add some template specialization to the 64bit RNGs provided here. This works well in principle, but has some disadvantages:
Vendor in the distribution functions from boost.random and remove the general behavior in favor of code making use of the richer interface of random_64bit_generator. License wise this is fine according to https://www.gnu.org/licenses/license-list.en.html#boost.
Go for a function interface normal(rng, n, mean, sd) etc., similar to the already functional sample() interface.
Extend random_64bit_generator further with methods normal(mean, sd) etc. In this case it would make sense to move the implementation of these methods into separate *.ipp files included after the class declaration. Due to the large tables for the Ziggurat method, this would increase the RNG objects size quite a bit.
At the moment I am using distribution functions from
boost.random
and add some template specialization to the 64bit RNGs provided here. This works well in principle, but has some disadvantages:random_64bit_generator
, c.f. Bug: Compile-time and runtime-polymorphism do not work together #65At the moment I see three possibilities:
boost.random
and remove the general behavior in favor of code making use of the richer interface ofrandom_64bit_generator
. License wise this is fine according to https://www.gnu.org/licenses/license-list.en.html#boost.normal(rng, n, mean, sd)
etc., similar to the already functionalsample()
interface.random_64bit_generator
further with methodsnormal(mean, sd)
etc. In this case it would make sense to move the implementation of these methods into separate*.ipp
files included after the class declaration. Due to the large tables for the Ziggurat method, this would increase the RNG objects size quite a bit.All three approaches would allow implementing the Ziggurat variant from https://github.com/cd-mcfarland/fast_prng and MT2001 for Gamma (c.f. #22).
The text was updated successfully, but these errors were encountered: