std.random2

[monarch_dodra]

On Tuesday, 8 January 2013 at 20:40:00 UTC, H. S. Teoh wrote:
> On Tue, Jan 08, 2013 at 07:46:46PM +0100, Joseph Rushton 
> Wakeling wrote:
>> On 01/08/2013 07:38 PM, ixid wrote:
>> >I imagine there has been some detailed discussion of the 
>> >std.nameX
>> >idea of libraries so forgive me if this has been discussed.
>> 
>> I appreciate your concern on this point, but I don't think 
>> it's the
>> right thing to focus on in this specific discussion.
>> 
>> What I really want address is: how do we get the design of 
>> std.random
>> _right_?
>> 
>> How we go about incorporating that new design into Phobos with
>> minimal hassle for users is a different issue and one we can 
>> face
>> when the time comes.
>
> For one thing, I'd say definitely make RNGs have reference 
> semantics.
> Passing by value just doesn't make sense; for large generators 
> it
> consumes too much stack space and risks stack overflow, and in 
> any case
> copying RNGs unintentionally causes duplicated sequences, which 
> is very
> bad.
>
> For those cases where you *want* to copy an RNG, it should be 
> made into
> a forward range and then you use .save explicitly.

I'd argue PRNG's should even be forward ranges. For one, the 
actual saving would be duplicating the PRNG payload itself (very 
costly). Further more, it would mean the danger of duplicate 
sequence still exist: a lot of algorithms, such a "fill", start 
by saving their input, and then iterating on the copy...

I'm all for them having "dup" though.

Worst case scenario, I had written an adaptor that turns a 
InputRangePRNG into a ForwardRangePRNG, but this is at the 
*explicit* request of the *user*, and not by any underlying 
algorithm.

And even then, I'd *still* advise against using this adaptor. If 
you *must* store and iterate on random values several time, just 
copy them in an array doing prng.take(N).array(). Clean, 
efficient, safe.

@jmdavis was against making them input ranges, saying input 
ranges just aren't useful compared to a forward range. I think 
that:
1. A PRNG naturally models input, and not forward.
2. Algorithms that operate on actual random sequenes shouldn't 
rely on the PRNG to be saveable anyways: A *true* RNG simply 
cannot provide save.

> I wonder if it even makes sense to force RNGs to inherit from a 
> common
> base class, so that reference semantics are enforced even for
> user-defined types. But this may be a bit too heavy-handed (and 
> it will
> alienate the no-GC crowd).

Force: No. However, we *can* provide tools to help with the 
operation though.

Since the recommended implementation of a PRNG is "pointer to 
payload", I had written an adapter template which took a "Stack 
payload implementation" and turned it into a reference semantic 
type. This meant I pretty much transformed all our PRNGs into 
reference ranges, without even touching any of their 
implementations.

If a user doesn't want it, fine.