On Jun 7, 9:24 am, Öö Tiib wrote:
> On Jun 7, 5:53 pm, orz gmail.com> wrote:
>> I had not actually realized that C++0x proposals included new RNG
>> stuff. It seems to be rather fond of the idea of a distribution & RNG
>> pair as a discrete object.
>> I'd rather go lighter on templates than
>> they like, at least for the stuff not targeted at researchers... in my
>> experience using that much C++y sugar involves slow compile times and
>> encountering many many compiler bugs.
> It is really not that heavy template wizardry like you seem to
> suspect. Boost random distributions are ~80 lines with comments.
> Random generators that substract_with_carry and lagged_fibonacci are
> longest ~500 lines. I doubt that you will notice compile time slow
> down using these.
> Templates are least intrusive. Users want to encapsulate and hide the
> details-schmetails anyway and have functions in interface that make
> sense within their application like oneFrom(100) or dice(3,6)+4.
> Bugs are most likely discovered for Boost since it has large user
> Performance issues you can never solve universally. When one has to
> refactor away boost usage because of performance, he will likely go
> raw all the way and not use some other library as well.
>> It's somewhat disappointing to see which RNG engines they incorporated
>> in Boost and TR1... mt19937 looks like their best, and it's not one of
>> my favorites by any means (large state size / slow seeding, medium
>> speed & quality (low quality relative to state size), and generally
>> reflects a mentality that emphasizes period length over any other
> You can add your own generator. You can propose it to boost. I bet
> that some sort of chaos_of_orz engine in Boost.Random gives you more
> fame and users than your own full library.
> I was more hoping that you say that their interface lacks some
> important functionality that people want to do with RNG. I feel that
> they have plenty of engines.
I suspect we just have different standards of template-heavy. I
consider STL template-heavy, and have seen dramatically slower
compiles when equivalent non-STL projects are switched to STL (though
admittedly precompiled headers were not used... not sure how much
impact they have under what circumstances), and see comments in
portable STL implementations (and Boost IIRC) about working around
various compiler bugs. Despite all that I consider STL worth the
cost. Still, I prefer to minimize the amount of that kind of thing
that my projects have to #include... some of the RNGs intended for
research in this project use systems of templates that are a little
complex, but I'd prefer to only use small simple templates in the
interface intended for the most basic and common activities.
adding a generator to Boost:
I suppose I could propose a generator or two to Boost, but there's no
way they would be interested in most of this package, as it has lots
of code for doing things Boost has no interest in, like statistical
tests. All I could really do is stick in a few more appropriate
RNGs. Which might be worthwhile and I'll take a glance at Boosts
contribution process, but that's not really my focus. I suppose I
could modify my RNG interface to match Boosts, but that's a fairly
major change, and I'd prefer to offer an interface to basic
functionality that's less templated than Boost.
interface features missing from Boost / TR1:
I expect they'll support all the basic features. Although... I can't
actually find any kind of serialization / save & restore type
functionality in their interface... probably an omission they'll fix
sometime soon, or maybe it's there and I'm just not seeing it. And my
current codebase includes interfaces to allow any RNG to act as an
entropy accumulator, though in retrospect I've decided that that's not
a great idea and that portion of the interface is omitted from the
list of methods I posted above.