(This PR furthers refines/stabilizes the new random engine, with no interface change to published as of 12.0)
ofRandomEngineDistributions rely on a std::mersenne_twister_engine instance seeded at ofInit() that end users don’t have to worry about. By default, it is fast and fine and multi-thread-safe (better than before's rand()). Also its results are mandated by the standard, so it is predictively cross-platform (whereas, for example, default_engine is left implementation/platform specific). That design decision to go with MT was thus aligned to standard/best practices in usage.
That being said, discussions around the topic of pseudorandomness and generators are ongoing and MT is certainly not the “absolute final” random engine. In order to allow exploration of the effect of the generator math to generative processes, the random methods have been adapted to support an additional Engine parameter, defaulting to the built-in one. (so no apparent change by default).
This modification, in essence, is that instead of always passing of::random::gen() to the distributions as the initial implementation was doing, it’s passing an argument that defaults to of::random::gen(). some template rules added to prevent confusion with defaults interpretation. The changes seem deeper than they are; some reformatting/simplifying also occured.
The end result is that interested parties are now able to swap the builtin engine for their own at call site (either by using some other stdlib-provided engines, or writing their own against the interface). at that point one might ask why go through ofRandom* at all? Bassically to facilite comparables, and integration of glm::vec2,3,4/FloatColor makes it easy to work with the usual OF objects.
This also allows to run multiple engines in parallel, which might be of interest if one is interested in seeding, and wishes to seed together different groups of random operations (effectively allowing “layered” seeding).
In addition to the modularisation, this includes ofFloatColor support where it makes sense and a bunch of typos & docs fixes, and touch ups on the 2 related random examples (The RandomExplorer devApp which displays the different distributions in action and their cost, and RandomExample which is simpler to read and serves as a test for most possible template combos).
ofTheo
commented
1 month ago
(This PR furthers refines/stabilizes the new random engine, with no interface change to published as of 12.0)
ofRandomEngineDistributions rely on a
std::mersenne_twister_engineinstance seeded atofInit()that end users don’t have to worry about. By default, it is fast and fine and multi-thread-safe (better than before'srand()). Also its results are mandated by the standard, so it is predictively cross-platform (whereas, for example,default_engineis left implementation/platform specific). That design decision to go with MT was thus aligned to standard/best practices in usage.That being said, discussions around the topic of pseudorandomness and generators are ongoing and MT is certainly not the “absolute final” random engine. In order to allow exploration of the effect of the generator math to generative processes, the random methods have been adapted to support an additional Engine parameter, defaulting to the built-in one. (so no apparent change by default).
This modification, in essence, is that instead of always passing
of::random::gen()to the distributions as the initial implementation was doing, it’s passing an argument that defaults toof::random::gen(). some template rules added to prevent confusion with defaults interpretation. The changes seem deeper than they are; some reformatting/simplifying also occured.The end result is that interested parties are now able to swap the builtin engine for their own at call site (either by using some other stdlib-provided engines, or writing their own against the interface). at that point one might ask why go through ofRandom* at all? Bassically to facilite comparables, and integration of glm::vec2,3,4/FloatColor makes it easy to work with the usual OF objects.
This also allows to run multiple engines in parallel, which might be of interest if one is interested in seeding, and wishes to seed together different groups of random operations (effectively allowing “layered” seeding).
In addition to the modularisation, this includes
ofFloatColorsupport where it makes sense and a bunch of typos & docs fixes, and touch ups on the 2 related random examples (The RandomExplorer devApp which displays the different distributions in action and their cost, and RandomExample which is simpler to read and serves as a test for most possible template combos).