I'll look into your paper! We have an interest in parallel rng for a Monte Carlo project, and after asking about boost efforts in this area here, and then after reading about TRNG, we decided to give TRNG a try because it looks very well designed. Our code will have a plugable prng design, so from that point of view I have no real preference of you idea being part of boost, TRNG or self-hosted. Being part of boost would be a slight benefit because it reduces the number of external dependencies to just boost in our project.
At the moment It might be most logical to contribute to TRNG because that is mature and well designed, but that's my very subjective guess, and I'm fine wherever it lands.
But first I should read your paper!
Thijs
Our work is definitely complementary to TRNG. We go beyond TRNG by arguing that if you use pseudo-random functions (which we call counter-based PRNGs in the paper), in lieu of conventional PRNGs, then things like 'skip' and 'jump' and 'jump2' become moot. You simply don't need them. On the other hand, if you have pseudo-random functions, then it's easy to implement skip() and jump() and jump2() for the benefit of applications that are already coded to a TRNG-like APIl. In fact, I'll probably do that in a future release of the Random123 library.
Still, I would be pleased if our work became part of boost, and that boost wouuld be enhanced by its inclusion, so I'm still interested in finding a way to fit Random123 into boost.
I'm looking into the lib now, and I must say that the counter based concept is very interesting. I like it a lot, and I hope that you would also preserve this state-less approach if you align it with boost. At first look it would be nice if this would indeed become part of boost. As a boost user I would vote for inclusion if there was a vote. Cheers, Thijs