Ranges and random numbers -- again

monarch_dodra monarchdodra at gmail.com
Tue Jun 18 12:32:30 PDT 2013


On Tuesday, 18 June 2013 at 19:21:23 UTC, Andrei Alexandrescu 
wrote:
> On 6/18/13 2:11 PM, Jonathan M Davis wrote:
>> On Tuesday, June 18, 2013 10:39:38 Andrei Alexandrescu wrote:
>>> On 6/18/13 10:16 AM, H. S. Teoh wrote:
>>>> I say again that RNGs being passed by value is a major BUG. 
>>>> The above
>>>> situation is a prime example of this problem. We *need* to 
>>>> make RNGs
>>>> passed by reference. For situations where you *want* to 
>>>> duplicate a
>>>> pseudo random sequence, an explicit method should be 
>>>> provided to clone
>>>> the RNG. Duplication of RNGs should never be implicit.
>>>
>>> Occasionally copying a RNG's state is useful, but I agree 
>>> most of the
>>> time you want to just take a reference to it.
>>>
>>> I think a good way toward a solution is
>>> http://d.puremagic.com/issues/show_bug.cgi?id=10404.
>>
>> That may be a good way to go about it, but the default such as 
>> what rndGen
>> returns really should be a reference type, and only ranges 
>> whose state can
>> actually be copied such that continuing to iterate over them 
>> gives the same
>> values should be forward ranges IMHO. Using Class!T might be 
>> able to make it
>> so that we can avoid needing a std.random2, but we'll probably 
>> still need some
>> minor code breakage in there somewhere.
>>
>> - Jonathan M Davis
>
> How about defining rndGenRef and putting rndGen on the 
> deprecation path?
>
> Andrei

Even with 10404, I still think we'd need a new module. An adaptor 
helps, but these ranges really need to be ref by default (amongst 
other changes). We'd probably have to end up with MersenneRef, as 
well as pretty much everything else...

Also: Class!PRNG.save would not actually save, it would merely 
return a copy of its PRNG payload, and not a new class instance. 
This could be problematic (for starters, it wouldn't qualify for 
forward range...)


More information about the Digitalmars-d mailing list