Hi folks, we do not often get the chance to break API; releases like 3.8 are such opportunities.
Not so long ago, we (I think it was Stefan, in fact) replaced a bad random generator with boost::mt19937 (a Mersenne Twister implementation with both known sufficient statistical properties and known bad speed). After that, we had to fix fastnoise_source and other blocks (mainly, because they were using non-threadsafe libc functions at runtime) by introducing our own implementation of XOROSHIRO128+¹. Should we be switching out the generator in gr::random to use that? Pro: + Way, way faster + Getting rid of yet another boost thing² + Consolidation of RNGs used + Being in control of the RNG allows us to keep it's API stable for as long as we want³ Contra: - API change - Code change that's not 100% necessary What do you think? Best regards, Marcus ¹ That's a relatively well-tested algorithm with high speed, low memory footprint, and in our implementation, isolated state. It's statistical properties are good to very good, but it's not been in as broad use as MT19937. I don't think we'll find bugs in it (I've run a good amount of statistical analysis on it). ² That exact RNG was a source of trouble before – somewhere around 1.48, IIRC, Boost decided to move its namespace without warning or documentation. That's the main anecdote why I'm weary of Boost. ³ Python 2->3 changed semantics for a couple of random generators, and some of that broke GR code, which is why I'm interested in having control over our RNG. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
