Page 1 of 2

qfcl/random

Posted: August 7th, 2012, 1:21 am
by MiloRambaldi
Just in case anyone is wondering: As previously mentioned, in version 0.3, I generalized the mersenne twister code to allow for arbitrary linear generators modulo finite. A month or so ago, I noticed that using the new code, MT19937 was about 25% slower than before (and thus 25% slower than boost. The test program is qfcl/test/speed_test). While this probably won't make much of a difference when generating actual variates (as opposed to raw PRNGs), I was not happy with this. I was in fact expecting a slight speed up with the new design. I looked at the assembly code output, and could not see anything obvious (in fact the new design has much smaller assembly output). Profiling, including measuring the latency of short code segments is rather nontrivial (the profiler included with VC10 seems to be useless for this). Since this seems to be a skill that a library designer should have, I decided it was a worthwhile effort to profile the PRNGs. I haven't drilled down quite far enough yet, but I have a few tools in qfcl/test: timer_latency, engine_speed and engine_profiler. We now also have a DescriptiveStatistics class for computing and displaying statistical properties of a given sequence of data (it was originally designed a long time ago, and is not quite how I would do things now) ... I couldn't find anything like this in boost.Here is example output from engine_profiler. More details are still needed...engine_profiler -n -r 40

qfcl/random

Posted: August 22nd, 2012, 2:18 am
by MiloRambaldi
I've done more work on the tools in qfcl/test: timer_latency, engine_speed and engine_profiler. I am now using boost.Program_options to make the tools more usable with command line options, and I would recommend it. For example,engine_profiler.exe -hProfiling is taking longer than I thought, so I will continue with some other things. I think to submit to boost only 2 more things need to be done: 1) get the build working on a unix type platform 2) provide complete documentation.

qfcl/random

Posted: August 22nd, 2012, 4:49 am
by Cuchulainn
General question: would it be useful to have default values in traits classes? More generally, is it easy to integate in a non-command line environment?

qfcl/random

Posted: August 23rd, 2012, 11:54 am
by MiloRambaldi
QuoteOriginally posted by: CuchulainnGeneral question: would it be useful to have default values in traits classes? I'm not clear what you are asking about, the engine_traits class? Perhaps this will be clearer once the documentation is complete?QuoteMore generally, is it easy to integate in a non-command line environment?As far as boost.Program_options, it can handle configuration files or combined config file/command line args. However, I don't think it would be helpful for interactive input.As for the profiling tools, they were just meant for me to profile the random number generation. If there was an interest, I don't see any difficulty in moving to a different environment.

qfcl/random

Posted: August 25th, 2012, 10:05 am
by Cuchulainn
The rationale for traits (Alexandrescu calls "baggage classes") is to avoid too many template parameters and to let the SUPPLIER provide 'don't care' values for the USER.Here is a simple example.

qfcl/random

Posted: August 31st, 2012, 9:30 pm
by MiloRambaldi
QuoteOriginally posted by: CuchulainnThe rationale for traits (Alexandrescu calls "baggage classes") is to avoid too many template parameters and to let the SUPPLIER provide 'don't care' values for the USER.Here is a simple example.I read about that in "C++ Templates: The Complete Guide". I introduced engine_traits because for example, boost::mersenne_twister has 14 template parameters and should probably have more for things such as the default seed. I'm not sure if my traits follow the usual idea. I will need to review the code when writing the documentation.

qfcl/random

Posted: September 8th, 2014, 2:34 pm
by Cuchulainn
A question for the RNG tsars:Is std::random_device a good way to generate seeds for RNG in C++ 11? I ported some code from Boost to C++ 11 to sees if it all works.

qfcl/random

Posted: September 25th, 2014, 5:17 pm
by Cuchulainn
This links is for generating variates from the non-central chi^2 distribution here1. The algorithm comes from Glasserman's book page 124. What is the original source? How 'good' is the approximation?1. The () member has an if-else test on k (degrees of freedom?). So, if we wish to compute an array of variates ==> the value of k is checked each time even though it is constant. Maybe all compilers optimize this but that's not the point. Mathematica does it like this You can give it a scalar, vector or matrix and get the same return type.

qfcl/random

Posted: September 29th, 2014, 5:28 pm
by Cuchulainn
1. I have Glasserman but the original source seems to be Johnson and Kotz Vol. 2 Continuous distributions.2. Some tests showed indeed if .. else does not seem to be a bottleneck.

qfcl/random

Posted: October 13th, 2014, 9:02 am
by Cuchulainn
QuoteThis links is for generating variates from the non-central chi^2 distribution hereAs well as this approach why not have a lite C version without all that Boost overhead? Just use a free function. Then it can be integrated into other libraries, and not just Boost-based. Now there is only one choice which is Boost which is not yet shipping.A more flexible solution would be less dependent on Boost. This is the library-independent part and is the meat (can the if-else be removed? avoid branching):

qfcl/random

Posted: January 18th, 2015, 1:01 pm
by Polter
Looks interesting: http://www.pcg-random.org/

qfcl/random

Posted: January 25th, 2015, 1:43 pm
by Cuchulainn
pcg: I did not see anywhere any mention of its thread-safeness (or otherwise)... especially in parallel loops. This feature is so fundamental but has anyone really solved it? ==The only thing I see in C++11 ishttp://en.cppreference.com/w/cpp/numeric/random/seed_seqso that each thread has its own RNG.