🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: sci.math.stat
Article #122

Re: "True" REG (was re: random number generator)

#122
From: Herman Rubin
Date: Mon, 03 Aug 1992 14:08
129 lines
7460 bytes
In article <1143@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt) writes:
>In article <55805@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>In article <1130@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt) writes:
>>>1.	Says who they're _really_ random? Sure we like to think so, but
>	[what about the prcision of the measurement device?]

>>Thes problems you have stated are not the major ones.  If one uses 
>>radioactive counts, the process is as close to independent as it
>>is unbiased, and long-term effects are essentially impossible.
>>HOWEVER, there is no way of testing them beyond the .001 level
>>of randomness, and there are good reasons for questioning .00001
>>on the physical grounds of the asymmetry of counters when changing.

>I am not complaining that the radioactive decay has long term
>correlations. I am pointing to the fact that there is a problem with
>controlling oscillations in the measurement device. You will be well
>within your rights to claim that a time base can be established to
>much better than 1 part in 10^10, but it is expensive to do so at
>bandwidths that can compete with algorithmic generators.

The time base of 10^7 bps is based on the assumption that a dead time
of better than 10^-8 second can be obtained.  I am far more mistrustful
of thermal generators.  The limiting rate above is due to the fact that
the counter may be in the process of changing when an interrogation or
stop signal arrives.

>Now I think 10^7 bps is a reasonable rate to compete with workstations,
>and so we need to control the frequency standard of the counter to drift
>less that 1 Hz per hour. This is do-able, but you have some thermal
>questions to worry about if you put the device in the computer.  This
>gets you to the level of correlations you get with 32-bit algorithms,
>but I doubt this will be viewed as a vast improvement. But when you
>want to go to the level of performance of a 48-bit generator, you have
>to control your time base to 1 Hz per 60K hours. If this is not a _major_
>problem for an economically viable device I'm surprised. But nonetheless
>I can go to a 128 bit generator and there is no hope left for the analog
>generator. 1 Hz per 10^28 hours is not in the cards, (10^28 hours = longer
>than the life of the universe so far, and by a long chalk.)

>>There are ways to overcome this, and they are not complicated.  If
>>one combines with XOR several streams, the problems should disappear.

>Not at all. If they have the same resonance, XOR'ing two streams together
>will not (generically) do anything for the correlations.

I do not believe that one will have a long-term periodic component; at 
best there will be a drifting bias.  Now if one has a situation where
the probability of a bit is 1 is .5 within a factor of .01 given all
other bits, these can be XOR'ed safely, even within the same stream.
Drifting of the frequency response can only improve the randomness.
It is even less than a non-problem.

I also believe it is a mistake to look at such trivia as correlation of
pseudo-random numbers.  The ways I would use random numbers could not
tolerate any such thing as 128-bit units; often I would use bytes, or
even bits.  Lack of correlation is far from independence.  The 
congruential generators are completely dead for the use of individual
bits.

>>One problem of pseudo-random numbers is the problem of either having
>>a not good enough, or a too good, frequency response.  By chance, there
>>should be a few rather large spectral points.

>You mean white noise samples aren't white? OK. But if you have a resonance
>in the measurement device, all your samples will have the _same_ resonance,
>and I don't call that white noise.

But I do not see that resonance in the measuring device is of any great
importance unless it involves strong dependence.  Even with thermal
noise, if a bit at one time only influences bits at other times by
.01, this is a not a problem if the XORing is used.  

>>>3.	You can't prove theorems about their outputs very easily. This
>>>	is similar to (1), but it can also be a defect of some algorithms
>>>	too.

>>I do not see that this is a problem, if the points I have mentioned above
>>are taken care of.

>I'm unconvinced that you can take care of them. Call me new-fashioned, but
>I'm happier about precise descriptions of digital circuits than I am
>with analog devices.

The point about the use of simulation is that the calculations cannot be
made in a reasonable length of time.  If regularity is appropriate, quasi-
random numbers, which have good equidistribution properties, but no
independence properties, are likely to do a better job.  But if one is
relying on statistical properties, using a deterministic sequence is 
asking for trouble.  Remember than any PRNG sequence will fail any
statisical test that it came from the process.

When I did some simulations where each sample point used 256 normal
random variables and 256 exponential random variables, I would have
been skating on thin ice to rely on such numbers.

>>>The way I look at it, the problem with 'natural' RNG is that the market
>>>is small for it, and so the use of general purpose hardware is always
>>>economically favored - i.e. algorithmic RNG.

There is a lot of simulation being done, and frankly I am suspicious of
much of it, because the systematic pseudo-random numbers may very well
interact with each other.  This is especially important in simulations
where entire processes are generated.  

>>Algorithmic RNG is likely to have some hidden flaws.  There is the 
>>matter of cost, but it seems that some physical random numbers are
>>needed to give reasonable assurance that they will not occur.  

>Actually, I like the idea of blowing off white noise altogether, and
>using known deterministic equidistributed systems for the theory. There
>is a certain motion in this direction with special algebraic points to
>do integration instead of Monte Carlo.

These are the quasi-random numbers I mentioned above.  If the functions
you are integrating are smooth enough, and a uniform distribution is
reasonable, this is fine.  There are other situations where it might
work, also.  But the now-popular Gibbs sampler, and other similar
schemes, seem to have little chance with it.

>One 'cute' example would be to use succesive digits of pi as uniformly
>distributed digits. How do statisticians view this heresy? 

Dangerous.  Even if pi is a weakly normal number, asymptotics does not
help.  It may be useful now, but it may not.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Technical Details
Message-ID: <55845@mentor.cc.purdue.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
References: <1130@kepler1.rentec.com> <55805@mentor.cc.purdue.edu> <1143@kepler1.rentec.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: sci.math.stat
Subject: Re: "True" REG (was re: random number generator)
Keywords: pseudo-random, C , uniform, normal
Message-ID: <55845@mentor.cc.purdue.edu>
Date: 3 Aug 92 14:08:35 GMT
References: <1130@kepler1.rentec.com> <55805@mentor.cc.purdue.edu> <1143@kepler1.rentec.com>
Sender: news@mentor.cc.purdue.edu
Organization: Purdue University Statistics Department
Lines: 129