[Q]:Generate Unique ID's

[Anton Vredegoor]

"Tim Peters" <tim.one at comcast.net> wrote:

>The bit-for-bit reproducibility of a PRNG is vital in many applications of
>RNGs, for debugging and verification.  Cryptography is just one application
>of RNGs, and its needs are extreme.  On the box I'm typing at right now (an
>866 MHz Pentium III), there's also that the Twister generates pseudo-random
>numbers much faster from Python than the Intel HW RNG generates them from
>pure C code -- monitoring thermal noise in a physical system is a

Could you please give a pointer to the C-code  you are using? I'm
currently polishing up some code I posted a while ago and having a
look at other implementations might be beneficial. 

By the way, I believe the Intel HW RNG is implemented by the chipset
on the MB and is not present in the Pentium processor chip itself.
(Probably you know this but some other readers might like to know
too.)

>time-consuming process.  For most uses of RNGs, I'd much rather have the
>speed.  Note that HW RNGs, and the software driving them, aren't immune to
>bugs either -- there's no escape from the general rule that an algorithm
>relying on RNGs has to be verified by statistical testing, and having
>another high-quality source of RNGs is helpful in that even if you intend to
>use truly random bits in deployment.

What comes below here is probably a philosophic point so take it with
a grain of salt :-) 

Suppose you are trying to convince a club of bridge-players to use
your bridge-dealing software. It probably would not matter to them if
you knew which dealing is going to come next as long as they don't
know you know. 

However, there's also a slight possibility that putting some photons
in a straightjacket by deterministically fixing the order of all
bridge dealings beforehand might degrade the number of possible paths
the future can take.

I wonder which Python zen applies here, "Refuse the temptation to
guess" or perhaps "Practicality beats purity" ? 

Anton