Dconf 2015 talks...

[Joseph Rushton Wakeling via Digitalmars-d]

On Monday, 25 January 2016 at 13:05:46 UTC, Era Scarecrow wrote:
>  Finally getting around to watching all the talks, all good 
> stuff :) Figured I'd make a thread talking about things I came 
> across and perhaps get into a discussion on them in detail.
>
>  Anyways I'm watching the talk with Joseph Wakeling involving 
> RNG and I wonder, is that still a problem or not?

It's still an issue, at least partly because amid all other 
things in life, I haven't had much opportunity to sit down and 
focus on it :-(

>  I ask since the simplest and most correct thing I can think of 
> is to use the heap for a referenced state, and dup would then 
> duplicate the state properly while otherwise the RNG problems 
> go away that most of the talk went on about.
>
>  It's possible I've been out of the loop and this has already 
> been solved. Not sure yet, I haven't looked closely at any of 
> the sources or the language updates.
>
>  So... time for some rusty D prototyping.
>
> [code]
> struct RNG {
>   int* state;
>
>   this(int seed) {
>     state = new int;
>     *state = seed;
>   }
>
>   //if you provide a pointer, we don't rely on the heap/gc at 
> all...
>   //maybe a small stack based allocator could be useful for 
> this?
>   this(int* seed) { state = seed; }
>
>   //dup instead of save, so it's not a forward range
>   RNG dup() { return RNG(*state); }
>
>   //popfront, front & empty as expected
> }
> [/code]

The major problems are not so much with RNGs per se (note that 
your approach can actually be much more nicely implemented as a 
final class).  It's all the functionality that _wraps_ RNGs, such 
as random algorithms like randomCover and randomSample, or a D 
equivalent of C++'s random distributions.  These need to also be 
reference types (for their internal state as well as the RNG they 
wrap), and here it gets very tricky to avoid nasty situations 
with lots of allocations and frees (when ideally, you'd like 
stuff like this to be stack only).

Don't even ask about how complicated a `.dup` method gets when 
you start trying to extend to such entities. :-(