Searching \ for 'Generating Random Numbers' in subject line. ()
Make payments with PayPal - it's fast, free and secure! 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.
PICList Thread
'Generating Random Numbers'
1996\06\24@115812 by myke predko

flavicon
face
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

1996\06\24@143156 by Mark K Sullivan

flavicon
face
>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 -

1996\06\24@214043 by fastfwd

face
flavicon
face
Mark K Sullivan <spam_OUTPICLISTTakeThisOuTspamMITVMA.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
sequence (especially if your counter isn't already fast enough to
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 - .....fastfwdKILLspamspam@spam@ix.netcom.com
Fast Forward Engineering, Vista, California
http://www.geocities.com/SiliconValley/2499

1996\06\25@205119 by Mark K Sullivan

flavicon
face
>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
start with, each new pseudo-randmo number has a fixed one-to-one correspondence
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 -

1996\06\25@224952 by John Payson

flavicon
face
>                         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.

1996\06\26@032728 by fastfwd

face
flavicon
face
Mark K Sullivan <PICLISTspamKILLspamMITVMA.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 - .....fastfwdKILLspamspam.....ix.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...