Long time members of this forum may recall that I once swore a bloody oath to get my PC to produce real random numbers, not pseudo randoms like Mersenne, and certainly not in any way like the C++/VBA rand() functions.I would like a couple of Beta testers, if anyone wants a source of high quality Random numbers Entropy of 7.999999 bits per byte, serial correlation <0.00004, and chi squared detects no "mechanical" bits at all.Depending upon your machine it delivers 500k-1.3 million single precision random floats per second.The first versions used hooks into the Win32 kernel to pick up machine events, reasoning that these were the result of physical process and thus really random. Not everyone agreed with this, and it was tricky to get a good level of performance; also some Alpha versions had a tendency to take control of the mouse and move it around the screen, which was frankly rather scary when it first happened on the tube. But it doesn't do that any more, though the other tube dwellers still give me funny looks writing C++ on the Central Line, muttering about black noise.

I would like to try.Bruno

Do you mean you need computer time to produce random numbers ?I'm ok to let my computer crush numbers at night for some time, if you give source code for your prg.

Have you send the results through the DIEHARD tests?

> I would like a couple of Beta testers, if anyone wants a source of high quality Random numbers Do you mean like rand48() as on Lnux, a bit better than rand()? Can I use it to test SDE, MC stuff?

Do you mean like rand48() as on Lnux, a bit better than rand()? No, they are algorithmic, this is real noise turned into reals.I'll be doing the DieHard stuff on the latest version, the final test will be on the reals that come out. Currently I generate a sequence of bytes and map them to reals by casting 4 bytes to a 32 bit integer.This is then cast to a double, and divided by 2^32, giving numbers in the (0..1) range.This is not quite perfect. Floating point representation has values that don't show up, and there are a tiny set of numbers that will occur twice as often as they should. I think I've worked that out as 64 in 4 billion, with a corresponding 64 that cannot ever occur.This applies to double precisions as well, though of course the ratios are better.Something vaguely bugs be about this conversion, so if anyone has a better idea I'm interested.I'm also looking at a generator for the normal distribution, but by "brute force" of summing N numbers. Many algortithms for this genertate artifacts, as aI recall Box-Muller has a pronounced step pattern. I'm working out the optimal value for N, and thoughts on this are welcome as well.Do you mean you need computer time to produce random numbers ? if you give source code for your prgI've promised someone 40 gb of random numbers, but I can now do that in a sensible time.The top grade of performance is got by the "head start" cache it can put on your disk. This can work with my "Eater" tool , which takes a mildly random file, and ingests the randomness of other files. JPGs, MP3s et al are "natural processes" but aren't actually all that random. The Eater merges them in, and overnight produces a gB of randomness.You're quite welcome to the source, once it is cleaned up.Actually, you're quite welcome to the source now, if you have a strong stomach and promise not to show it to anyone, since it is rather dodgy.

Do you mean like rand48() as on Lnux, a bit better than rand()? No, those are algorithmic, this is real noise turned into reals.I'll be doing the DieHard stuff on the latest version, the final test will be on the reals that come out. Currently I generate a sequence of bytes and map them to reals by casting 4 bytes to a 32 bit integer.This is then cast to a double, and divided by 2^32, giving numbers in the [0..1] range. The result is then cast back into a single float, to be tyhe same asalgorithmic RNGs.This is not quite perfect. Floating point representation has values that don't show up, and there are a tiny set of numbers that will occur twice as often as they should. I think I've worked that out as 64 in 4 billion, with a corresponding 64 that cannot ever occur.This applies to double precisions as well, though of course the ratios are better.Something vaguely bugs be about this conversion, so if anyone has a better idea I'm interested.I'm also looking at a generator for the normal distribution, but by "brute force" of summing N numbers. Many algortithms for this generate non-random artifacts, as I recall Box-Muller has a pronounced step pattern. I'm working out the optimal value for N, and thoughts on this are welcome as well.Do you mean you need computer time to produce random numbers ? if you give source code for your prgI've promised someone 40 gb of random numbers, but I can now do that in a sensible time.The top grade of performance is got by the "head start" cache it can put on your disk. This can work with my "Eater" tool , which takes a mildly random file, and ingests the randomness of other files. JPGs, MP3s et al are "natural processes" but aren't actually all that random. The Eater merges them in, and overnight produces a gB of randomness.You're quite welcome to the source, once it is cleaned up.Actually, you're quite welcome to the source now, if you have a strong stomach and promise not to show it to anyone, since it is rather dodgy.

I'll be doing the DieHard stuff on the latest version, the final test will be on the reals that come out. I'll wait for the results It's been a long time but AFAIK you can use a simple binary file, no need to convert to doubles etc. BTW, do you know the Yarrow Engine? It sounds like you are reinventing the wheel... Source code available from the link.

Some people want doubles & floats, certainly as a plug in replacement for rand/rand48 et al.Casting an array of bits to a double will cause bad things, really bad things, try to imagine the particles in your body exploding outwards at the speed of light, and time itself ending.Didn't know about the Yarrow engine, certainly looks roughly the same as my earllier performance hook version. Mine ran into reasonable criticism that that the basic numbers can be the result of algorithms, and performance stuff is ironically a bit slow.My second stab uses noise.

Some people want doubles & floats, certainly as a plug in replacement for rand/rand48 et al.Casting an array of bits to a double will cause bad things, really bad things, try to imagine the particles in your body exploding outwards at the speed of light, and time itself ending.Good thing I never tried that... I wasn't talking about casting a BYTE[8] to a double. The algorithm you described for converting to floating point values is close to what most people use. My remark was about the DIEHARD tests which I seem to remember take a binary file of a fixed size as input.Other possibilities for "better" (suited for cryptographic applications) generators include CryptGenRandom (win32) or Source code for generating randomness . In general, it doesn't seem to be necessary to only use "true" random numbers except for cryptography where the predictability of sequences is a problem. Occasionally seeding a good and fast PRNG with some entropy from the system might be the best choice for simulations.

To be sure, PRNGs are quick and easy but most seem to suffer from "artifacts", orbits, holes and the like, even if their repeat sequence is long.You're right that it is wise to seed any PRNG with real noise, and the bog standard use of time is not too bad., though obviously there is a sequential bias here since time stamps don't change all of the bitfield from one call to the next, the lest significant values change most. I've taken this as a challenge, because of people saying you can't get real randoms from a PC. My first goal was to show you can, and in idle moments have played with seeing if I can get a RRNG that is comparable in performance with PRNGs. My latest stuff is pretty fast, but it's damn hard to compete with the simple minded modulus used in VB's rnd(). However, I'm a bit more optimistic about generating the normally distributed values people in Quant finance use, since I can swap the moderately slow exp based implementations for some adds and a divide.

obviously there is a sequential bias here since time stamps don't change all of the bitfield from one call to the next, the lest significant values change most.That shouldn't matter too much with a good PRNG algorithm, but you are right. The seed itself should be "random" - whatever that is... To work around the artifacts, you could periodically reseed. That is btw what /dev/urandom on Linux does.However, I'm a bit more optimistic about generating the normally distributed values people in Quant finance use, since I can swap the moderately slow exp based implementations for some adds and a divide.I think you are talking about summing 12 uniform random numbers in the -0.5..+0.5 range. From my experience, Box-Muller is still faster as the RNG is more "expensive"./off for today...

DCFC,For faster performance in converting a long into a double in the range [0..1), we use the following C++ code which takes advantage of the IEEE representation of a double on an Intel machine: // Converts from unsigned long to double [0.0, 1.0) without division // by using IEEE memory representation of double unsigned long longValue = generateLong(); union { double asDouble; unsigned long asLong[2]; } convert; convert.asLong[0] = longValue << 20; convert.asLong[1] = (longValue >> 12) | 0x3FF00000L; return convert.asDouble - 1.0;As to conversion from the uniform to the gaussian distribution, we use an inverse cumulative normal function (like Moro's algorithm but with higher precision) instead of Box-Muller. I posted the C++ code for it here: http://www.wilmott.com/messageview.cfm? ... adid=17533

QuoteBeta testers wantedso what do you want beta tester to do ? could you talk about hardware requirements for your test.

The only requirement is a soundcard, doesn't even need to be connected to anything.Lots of electormagnetic hiss,pops, crackles, clicks appear if you turn the volume up real loud.