1st draft of complete class-based std.random successor

bearophile bearophileHUGS at lycos.com
Sun Mar 23 03:15:31 PDT 2014


Joseph Rushton Wakeling:

> I think all std.random functions now support a default RNG.

Is the issue is already fixed in std.random you can close it :-)


> However, I'd have thought that
>
>     int r = data.sample(1, rndGen).front;
>
> would have been a more efficient way to implement "choice", as 
> it can operate on any input range, as long as it has the 
> .length property; and it ought to be _much_ faster than even a 
> single call to randomCover.
>
> One could always use this as a default option, with a 
> specialization where data is a RandomAccessRange to use the 
> more efficient
>
>     int r = data[uniform!"[)"(0, data.length)];

The best thing is to add an efficient choice() function, so no 
efficiency mistake happens :-)


>> "Strongly pure random generator":
>> https://d.puremagic.com/issues/show_bug.cgi?id=5249
>
> .front and .popFront at least are pure for _all_ the RNGs 
> currently implemented in std.random2.generator.  See e.g.:
> https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L266-L272
> https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L506-L517
> https://github.com/WebDrake/std.random2/blob/master/std/random2/generator.d#L821-L834
>
> Of course this is not strongly pure in line with your request, 
> but it should enable use of these RNGs in many other scenarios 
> where purity is important.

So you are saying that those RNGs are already weakly pure and 
they can't become strongly pure because they take the engine as 
mutable class reference. And even if you design a very small 
random engine that can be created every time you call a random 
generator, the API of all the random functions is not compatible 
with it. So it's not a simple problem...


> This is a range implementation; there will also be a function 
> implementation, which will probably follow the inefficient 
> Box-Muller variant that uses 2 uniform random variates to 
> generate a single normal variate (as per the example you posted 
> in your feature request).

A possibility is to also add a less precise (more approximate) 
but faster function implementation.


Are the ddocs produced by std.random2 online somewhere?

Bye,
bearophile


More information about the Digitalmars-d-announce mailing list