Searching \ for 'Generating Random Numbers' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/method/math.htm?key=random
Search entire site for: 'Generating Random Numbers'.

Truncated match.
'Generating Random Numbers'
1996\06\24@115812 by

Hi Folks,

Sometime ago (last year?) somebody put on a method of getting random numbers
from the PIC by using power-up values.

Does anybody still have that explanation, code etcetera?

Right now, I am generating Random values by timing how long a key is held
down and I'm wondering if there is a more elegant way of doing this.

Thanx,

Myke
Myke

"We're Starfleet officers, weird is part of the job."

Capt. Catherine Janeway
>Right now, I am generating Random values by timing how long a key is held
>down and I'm wondering if there is a more elegant way of doing this.

That's probably the best way, provided your counter runs much faster than the
key down time and overflows many times during that period.  If not, consider
evaluating a standard pseudo-random sequence (see Knuth) at every tick instead
of simply counting.

Power up values in practice are not necessarily all that random.

- Mark Sullivan -
Mark K Sullivan <PICLISTMITVMA.MIT.EDU> wrote:

> >Right now, I am generating Random values by timing how long a key
> >is held down and I'm wondering if there is a more elegant way of
> >doing this.
>
> That's probably the best way, provided your counter runs much faster
> than the key down time and overflows many times during that period.
> If not, consider evaluating a standard pseudo-random sequence (see
> Knuth) at every tick instead of simply counting.
>
> Power up values in practice are not necessarily all that random.

Mark:

You're right about power-up values, but there's a flaw in your
previous paragraph:  No matter how much you permutate the
counter-value, you'll still only be choosing one of 2**n values
(where n is the width of your counter).

By adding execution cycles to turn the counter into a pseudo-random
roll over when it's simply being incremented), you'll make your
results LESS "random", not more.

The PIC's Watchdog Timer is based on an internal, poorly-controlled
RC oscillator... Perhaps a good way to get random values without any
user interaction would be to clear the WDT, start a counter, then
increment it until the PIC resets.  Since RAM is preserved through
the reset, you could then check the value.

A similar technique, by the way, can be used to CALIBRATE the
watchdog timer... Chip Gracey did this in Parallax's BASIC Stamp.

-Andy

Andrew Warren - fastfwdix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499
>I wrote my message under the assumption that the asynchronous event
>that was being timed was only used to SEED a pseudo-random number
>genarator.  Once the initial random seed was obtained, I figured
>that subsequent random values WOULD be generated by an LFSR or a
>linear-congruent generator or whatever.
>
>Does this clear things up, or do you still disagree with me?
>

It does indeed!  Of course you are right.

Does it make sense to you to use on-going asynchronous events to generate future
numbers?  If you only seed the generator once, then, no matter what value you
with the previous one.  If you use the async event every time, you should get
"real" random numbers.  The importance of this property of course dependes on
the application.

Either way, I think the original question is answered.

- Mark Sullivan -
>                         If you use the async event every time, you should get
> "real" random numbers.  The importance of this property of course dependes on
> the application.

Using related async events for random numbers will usually result in the
numbers themselves being related.  While the time between system startup
and the first keypress may be fairly random, sampling the time between
consecutive keypresses will often yield similar numbers over and over
again.  No matter how precisely you try to time such things, it is just
about impossible to make even the LSB's of a 1MHz counter really "random".
Correlational tendencies frequently leak through, but cannot be reliably
measured or modeled.

A common workaround to this is to try to, e.g., XOR the seed of a PRNG
with the "random" physical input periodically and hope that will produce
random numbers.  While this will often work, it is usually possible for
such systems to get into a bad state where the non-randomness of the PRNG
interacts badly with the non-randomness of the physical source and the
result is a really horrible random number generator.

Therefore, a common recommendation is to use a physical process to seed a
PRNG, but not to use it at all thereafter.  Instead, just choose a PRNG
which has suitable characteristics and use it.
Mark K Sullivan <PICLISTMITVMA.MIT.EDU> wrote:

> > Does this clear things up, or do you still disagree with me?
>
> It does indeed!

Good... Sorry for the lack of clarity in my first message.

> Does it make sense to you to use on-going asynchronous events to
> generate future numbers?  If you only seed the generator once, then,
> no matter what value you start with, each new pseudo-randmo number
> has a fixed one-to-one correspondence with the previous one.

True, but that's why you're using a pseudo-random number
generator.  If the generator's good, the future numbers will be
as random (by whatever criteria you use... flat spectral
distribution, etc.) as if each number were generated by its own
asynchronous physical process.

> The importance of this property of course dependes on the
> application.

Yes.  In many applications, of course, the repeatability of a
singly-seeded "random" sequence is actually an asset, especially
for testing purposes.

> Either way, I think the original question is answered.

Agreed, but this conversation has been interesting.

-Andy

Andrew Warren - fastfwdix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

More... (looser matching)
- Last day of these posts
- In 1996 , 1997 only
- Today
- New search...