[LAD] random curiosity

[Patrick Shirkey]

>
> Gabriel M. Beddingfield wrote:
>    
>>
>> On Tue, 26 Jan 2010, cal wrote:
>>
>>      
>>> old seed/sequence on every note. I've now got random_r in there and
>>> I'm comfortable with it, but at this stage I've no clear indication
>>> I've achieved anything valuable or even better :-).
>>>        
>>      
>>>  From 'man 3 random_r':
>>>        
>>      These functions are the reentrant equivalents of the
>>      functions described in random(3).  They are suitable for
>>      use in multithreaded programs where each thread needs to
>>      obtain an independent, reproducible sequence of random
>>      numbers.
>>
>> That is to say, if you need a reproduceable string of "random" numbers
>> on each thread (e.g. for unit testing), then random_r() is your man.
>> Otherwise, it sounds like more trouble than it's worth.
>>      
> As I understand it, zyn wants a reproducible sequence for mainstream,
> plus a reproducible per note sequence seeded according to the current
> point in the mainstream sequence. Interrupting and resuming the
> mainstream sequence was the issue I was looking to simplify. If you step
> over srandom_r(), it's really not any great trouble.
> .
>    
>> I.e. if every thread is just doing srandom_r(time(),buf), it's probably
>> not worth it.
>>      
> Probably true, but that's not quite the scenario being addressed. I saw
> potential value in reducing the per note ops going on.
>
>    
>> If random() is implemented without memory guards (atomic ops) on the
>> global variable... then it's possible that calling random() from two
>> different threads at the same time could give the same answer -- but so
>> what?
>>      
> Good question! Some times you simply have to have that little bit of extra
> quality of randomness in your life, even if it's just to make you imagine
> you feel better.
>
>    

The placebo randomness affect...

Patrick Shirkey
Boost Hardware Ltd