3V0-
Optimizing compilers can compact code in ways that no rational human would. Optimized code can be smaller then hand coded assembly.
There's no way in hell any compiler can optimise a small fast task to the level that a good human assembler coder can. Compilers can optimise large complex code to be better than what an assembler programmer can do easily. Those are 2 very different concepts.
MisterT-
The RNG I posted (the code is missing the initialization) is from the book "Numerical Recipes - The Art of Scientific Computing, 3rd edition". In the book it says: "It has a period of “only” 1.8e19, so it should not
be used by an application that makes more than 10^12 calls. With that restriction, we think that it will do just fine for 99.99% of all user applications".
Check your code again, you are only adding the prime number;
return v + 2685821657736338717LL;
which is an essentially useless step; adding ANY number after the algorithm itself.
but if you blended the prime number into the algorithm;
return v += 2685821657736338717LL;
it would start to be usable as a RNG. I'm guessing either your code or the book had a typo.
LTX71CM-
Computers don't do "random", I don't think Mr RB suggested the Black RNG was pure random, just that it had better entropy.
"Pure" random is in the eye of the beholder. Any process that produces a new number that cannot be predicted by knowing all the numbers before it meets my definition of random. There's no reason that that goal cannot be produced algorithmically. My process uses an algorithm, a 1Mbit cache and values held within the RNG engine. The algorithm may be known but what the algorithm does with the cache has random factors determined by the cache and by the engine. The result is *sufficiently* random that the next number in the sequence can't be predicted by the observer.
MisterT-
How it is impossible to predict something that your algorithm just generated?
To predict the next number generated you would need to know the entire contents of the 1Mbit cache, and the postion in the cache, and the state of the RNG engine. It is not possible for the observer to know those things based on previously generated numbers, so to predict means you must solve for every possible solution of cache content and cache index and engine values, and that brings you back to equal odds, ie your chance of guessing.
It doesn't take long to code my RNG engine up in C, feel free to play with it and run the data through your tests. Or use it in your commercial product, I don't care. It won't do the really fast megabits/sec RN generation you asked for in your other thread but it is sufficiently random with enough passes, if you need high quality RNG generated solely by algorithm without resorting to hardware tricks.