Practically Random Activity
statistical tests & psuedo- random number generators (RNGs, PRNGs)
Status: Beta
Brought to you by:
orz
Activity for Practically Random
-
orz posted a comment on discussion Open Discussion
Multiplication is... decent? I mean, it's fast, on a lot of CPUs, and tends to mix things better than add/xor. The class of CPUs it's fast on smaller than the class of CPUs that the basics (add, xor, shift) are fast on, so a PRNG that uses multiplication is inherently targeting a smaller niche. Not much smaller these days, since fast multiplication is pretty common. And low multiplication alone is never enough, you inherently need shifts, and probably add or xor too, or maybe just decimated output...
-
What? If a 4 word PRNG shows the (Extended+MaxFold) failures as: 16bit word => 2^36 16 bits is 2 bytes. 4 times 2 bytes is 8 bytes of state. Is that not saying that failures occur after 2^36 bytes with a state size of 8 bytes?
-
IgneousRed posted a comment on discussion Open Discussion
From what I understand, your stance is that multiplication should be avoided since it is too slow? I would totally agree with that stance 10years ago. But for last several years every CPU can do full multiply with decent speed. Given that it does alot more mixing than an add, I think it more than worth it's weight. When choosing a PRNG for low-end CPUs, it should be avoided. But why not list such RNGs for people to have a choice, and read it's Pros and Cons? MWC is a classic at this point, but adding...
-
Just now caught an error... And the fact that it fails at 2^36 bytes for an 8 byte state and 2^42 bytes for a 16 byte state would worry me. That is not what I wrote, also 8bit version has 32bit state, and failure after 2^30 is about as much as would be expected. The problem is that it scales bad.
-
Just now caught an error... And the fact that it fails at 2^36 bytes for an 8 byte state and 2^42 bytes for a 16 byte state would worry me. That is not what I wrote, also 8bit version has 32bit state, and failure after 2^30 is about as much as would be expected. The problem is that it scales bad.
-
The RNG I am currently making is indeed a CountingChaotic type and is almost twice as fast on AArch64 than SFC, without using multiplication and should be easy to make it SIMD . I will create another topic when my long tests confirm some things. Also I want to say thank you for creating this amazing software! Cant wait for the next version (been quite a while), hopefully the 0 generator won't make a fatal error, and for folded FPF test not failing randomly with data below 2^20 :D
-
The RNG I am currently making is indeed a CountingChaotic type and is almost twice as fast on AArch64 than SFC, without using multiplication and should be easyto make it SIMD . I will create another topic when my long tests confirm some things. Also I want to say thank you for creating this amazing software! Cant wait for the next version (been quite a while), hopefully the 0 generator won't make a fatal error, and for folded FPF test not failing randomly with data below 2^20 :D
-
The RNG I am currently making is indeed a CountingChaotic type and is almost twice as fast on AArch64 than SFC, without using multiplication and should be easily to make it SIMD . I will create another topic when my long tests confirm some things. Also I want to say thank you for creating this amazing software! Cant wait for the next version (been quite a while), hopefully the 0 generator won't make a fatal error, and for folded FPF test not failing randomly with data below 2^20 :D
-
Yeah, performance of high-end CPUs on short loops has been weird ever since... the early to mid 1990s I think? PPros. And these days it's not just high-end CPUs anymore. sfc is sort of optimized for x86. Not much really, but the value of the left-shift was chosen, at least in part, to work well with the LEA instruction on x86.
-
Probably not. I mean, if there are other PRNGs that seem comparable in most ways but are better quality, I'd tend to recommend the better quality ones for whatever niche they were competing in. And the fact that it fails at 2^36 bytes for an 8 byte state and 2^42 bytes for a 16 byte state would worry me. That implies that even if the 64-bit version passed very large tests, it's might be because the tests couldn't keep track of correlations at the right distances or whatever - and there would be a...
-
On my Mac M2 Pro incrementing by random odd number (instead of 1) speeds up SFC by almost 10%. Found this to be true also on my PRNGs.
-
If a 4 word PRNG shows the (Extended+MaxFold) failures as: 8bit word => 2^30 16bit word => 2^36 32bit word => 2^42 64bit word => 2^45+ It is not state efficient, but is that fine if it is fast? You surely won't name it "future-proof", but would you recommend 64bit version? And why/not? Also from https://pracrand.sourceforge.net/ I get the sense that you hold 8bit PRNGs to the same standard of randomness as 64bit ones, why is that? From my perspective If one uses 8bit on a micro-controller they probably...
-
PractRand targets normal integer sizes - 8, 16, 32, 64, and unknown. For a 24 bit source I would recommend either 8 (stdin8 / As8) or unknown (stdin / AsUnknown). Or better running tests twice, once on the lowest 16 bits and then again the highest 16 bits. Eventually the command line will get powerful enough to allow you to specify that, but it's not there yet, so currently you'll have use your own code to drop 8 bits out of every 24.
-
palxex posted a comment on discussion Open Discussion
Or could you please add stdin24?
-
Michael Niedermayer posted a comment on discussion Open Discussion
Well, i dont "have to" do it, iam just playing with this for fun. Brute force is a bit boring. So heres my implementation of finding the seeds from 10+ output values and probably too terse description of how that works. But bascially it iterates over the 17-19 MSB of a compute the corresponding MSB of b and c from that (c requires us to explore multiple cases) and then move around so we split the now "known" part of c so the lower part becomes the MSB of c and then check that. That allows us to discard...
-
Going from the output to the internal state looks quite feasible. Running the algorithm backwards should be even easier. The seed is simply the internal state 12 steps before output starts. There's probably some intelligent way to compute the state algebraically from the output, but if I had to do it, I'd just brute force it - guess a random value of 'c', use the output to calculate later values of 'c' from the guessed initial value, use the calculated values of c to calculate what the 3rd & 4th...
-
Hi all Wasnt sure i should start a new thread but i guess as its about sfc64 this would reach people interrested. I was playing around first wondering how hard it would be to find the seeds from the output and then instead looking for patterns in the output based on my plan on how to find the seeds from the output. The shortest code i found that shows statistical defects in sfc64 i got after maybe an hour today of looking into it is this: uint64_t v1 = 0, v0 = 0, c = 0, a = 0; for (int i = 0; i<128;...
-
Expanded test error "gap product is zero"
-
I tried some tests on the code you posted. TestU01: 1/1/1 That is, it fails 1 subtest (out of 15) of SmallCrush, 1 (out of 144) of Crush, and 1 (out of 160) of BigCrush. So about 10-15 seconds for first failure. In every case, it was a birthday spacings test that found bias. Also, some people like to run TestU01 on bit-backwards versions of PRNGs (because TestU01 is less stringent on the higher bits, completely skipping the highest IIRC) I also tried both bit-backwards and byte-backwards ; bit-backwards...
-
Arlet Ottens posted a comment on ticket #17
I've seen some failures reported on other tests (I remember MaxOft) as well, but with p-values around 1e-4, so not really definitive. The birthday spacings is the one that fails hard. I'll keep an eye on other results. In my code, the 48 bit LCG portion is fixed, and the 32 bit hash sequence is generated by an algorithm that tries out random sequences of candidate instructions . Each generator is then tested by calling PractRand, which I have modified to return a simple quality score. The set of...
-
No, wait, I'm confused. I hadn't touched PractRand in a while and was accidentally testing with version 0.92. Testing with version 0.95, it does adequately on those files at default settings. rng=RNG_file(d:\inc\out), seed=0 length= 1 gigabyte (2^30 bytes), time= 24.0 seconds Test Name Raw Processed Evaluation mod3n(5):(0,9-0) R= +74.0 p = 1.9e-40 FAIL !!! ...and 222 test result(s) without anomalies rng=RNG_file(d:\inc\out1), seed=0 length= 32 megabytes (2^25 bytes), time= 4.6 seconds Test Name Raw...
-
No, wait, I'm confused. I hadn't touched PractRand in a while and was accidentally testing with version 0.92. Testing with version 0.95, it does adequately on those files at default settings. rng=RNG_file(d:\inc\out), seed=0 length= 1 gigabyte (2^30 bytes), time= 24.0 seconds Test Name Raw Processed Evaluation mod3n(5):(0,9-0) R= +74.0 p = 1.9e-40 FAIL !!! ...and 222 test result(s) without anomalies rng=RNG_file(d:\inc\out1), seed=0 length= 32 megabytes (2^25 bytes), time= 4.6 seconds Test Name Raw...
-
No, wait, I'm confused. I hadn't touched PractRand in a while and was accidentally testing with version 0.92. Testing with version 0.95, it does adequately on those files at default settings. rng=RNG_file(d:\inc\out), seed=0 length= 1 gigabyte (2^30 bytes), time= 24.0 seconds Test Name Raw Processed Evaluation mod3n(5):(0,9-0) R= +74.0 p = 1.9e-40 FAIL !!! ...and 222 test result(s) without anomalies rng=RNG_file(d:\inc\out1), seed=0 length= 32 megabytes (2^25 bytes), time= 4.6 seconds Test Name Raw...
-
It is rather embarrassing that SmallCrush is detecting flaws that PractRand needs hours or more on. Perhaps I should have a small variant of the birthday spacings test incorporated in to the base test set... I presume it's all birthday spacings tests it's failing? Let's see... for this variation at least, the PRNG state transition function looks like an 48 bit LCG with additive constant 69, multiplicative constant 0x010101010101, and modulus 0x1000000000000, plus an 8-bit accumulator used in a rather...
-
Possibly related: I noticed this issue while working on a project to create a good PRNG for 8 bit targets, using a genetic/hill climbing algorithm that uses PractRand to test candidates. I've seen it happen quite regularly that PractRand gives a pass for 128GB or even 1TB, but that the same PRNG output fails in SmallCrush/Crush, usually on the BirthdaySpacings test. The same thing happened with the output files above. The contrast between PractRand running for an hour or more and seeing no problems...
-
Quirky, but it's looking like correct behavior to me so far. I think the third nibble out of each 64 bits has some kind of detectable pattern, and removing the first byte phase shifts that to the first nibble out of each 64 bits, which is much easier for PractRand to notice.
-
Both files fail SmallCrush: ~~~ ========= Summary results of SmallCrush ========= Version: TestU01 1.2.3 Generator: stdin Number of statistics: 15 Total CPU time: 00:00:06.00 The following tests gave p-values outside [0.001, 0.9990]: (eps means a value < 1.0e-300): (eps1 means a value < 1.0e-15): Test p-value 1 BirthdaySpacings eps All other tests were passed
-
Different results when 1 byte is skipped
-
I would also suggest changing "(x >> 8) % 2" to "((x >> 8) & 1)". They may look equivalent, but x is declared as a signed type, and modulus operations on signed types can result in negative values in C/C++. That never actually comes up in practice here because the sign bit of x is always clear for the code as-is, but the compiler won't figure that out and will add extra logic to handle negative values correctly on each modulus. Plus if the algorithm ever gets adjusted in a way that does allow the...
-
Greg Owens modified a comment on ticket #16
Thanks, this is indeed the problem. The author of the random algo found the problem. Every '0a' byte gets translated to '0d 0a' on the pipe.
-
Thanks, this is indeed the problem. The author of the random algo found the problem. Every '0a' byte gets translated to '0d 0a' on the pipe. He says he added a windows fix to the source code in github.
-
Big bug in Practrand 0.94 and 0.95 ?
-
Pretty sure that's a bug in your RNG's portability, not PractRand's. At a quick glance, your ADC implementation is bugged, though I don't quite see how that bug could lead to the results you see. Perhaps another bug is responsible.... actually, are you sure your RNG output isn't getting mangled by CR/LF issues somehow? That's what that looks like to me. If you still think PractRand is responsible, eliminate your RNG's portability as a potential source by saving its output to a file and checking that...
-
Big bug in Practrand 0.94 and 0.95 ?
-
Gregory Petrosyan posted a comment on discussion Open Discussion
FWIW, I've ran Pat5 test using PractRand pre0.95 on sfc64 10 times up to 128 TB, and did not observe any failures. I've also used the 0xdf7e5fd0802274af seed from your run, and it also passed up to 128 TB. Test output (and the patch I've used to only run the Pat5 test) is here: https://gist.github.com/flyingmutant/32a30cb09d130e1cd754ca3577f1d8b2
-
Munther posted a comment on discussion Open Discussion
Is there a ready executable file for Windows for PractRand to download
-
Aleksey Vaneev posted a comment on discussion Open Discussion
"Spike-logarithmic" is a moniker for beta distribution with alpha=0.5, beta=1. It's not exactly this beta distribution around 0; as beta distribution is infinite at 0, this "spike-logarithmic" diverges there.
-
I've composed a pretty simple program (in public domain) that quickly finds PRNG bit relationships going spike-logarithmic (or beta distribution with alpha=0.5, beta=1). This is not a meticulously-scientific test, because it needs tuning of "thrs" (threshold) to a reference "true random noise" (not having a theory), and to a block size. I only did the test to gain more self-confidence in PRVHASH. I did group-comparison based on PRNGs from https://github.com/lemire/testingRNG On spike-logarithmic...
-
Oh well, things depend on seed values, so checking several seeds is needed. So, I may be wrong about "tendency", as depending on seed various bit pairs pop up. Anyway, an interesting test IMO. Maybe someone can refine it further.
-
It considers 64-bit continous PRNG stream values, but can be scaled at will - e.g. 8-bit, 16-bit, 128-bit values. There may be problems in PRNG at different scales.
-
testpdf.cpp
-
I've composed a pretty simple program (in public domain) that quickly finds PRNG bit relationships going spike-logarithmic. This is not meticulously-scientific test, because it needs tuning of "thrs" (spike-logarithmic threshold) to a reference "true random noise" (not having a theory), and to a block size, and needs doomy "peer review". I only did the test to gain more self-confidence in PRVHASH. I did group-comparison based on PRNGs from https://github.com/lemire/testingRNG AESCTR, simple_lcg and...
-
Jirka posted a comment on discussion Open Discussion
Hi Lorenzo, I agree with your assessments! The speed of Ranlux++ is acceptable. The real issue is a fairly complex code - to mitigate it, one can directly compare the output of Ranlux++ against the output of the original Ranlux generator. Here is reference implementation: https://github.com/sibidanov/ranluxpp/blob/master/tests/ranlux_test.cxx#L137 BTW, Vigna added on his page a couple of generators called GMWC128 and GMWC256 which should be of very good quality while being at the same time fairly...
-
Lorenzo posted a comment on discussion Open Discussion
Hi Jirka, well done! A factor 3x in speed with respect to a very fast generator such as xoshiro256 is very probably more than acceptable in the vast majority of applications. Some of the original considerations made for RanLux++, although they are not at all damning, still apply: the implementation of the generator is fairly complex and the generator is not blazing fast. In any case, it's obviously good to have a fast implementation of such a famous generator. BTW, Vigna added on his page a couple...
-
Hello everybody! I have created binary packages of PractRand for Fedora and Red Hat Enterprise Linux distributions. Find here the list of available packages: https://src.fedoraproject.org/rpms/practrand You can install it with this command: dnf install practrand See man practrand-RNG_test for usage. Happy RNG testing:-) Jirka Example: testing Linux Kernel's /dev/random RNG: practrand-RNG_test stdin -tlmax 4G </dev/random practrand-RNG_test using PractRand version 0.95 RNG = RNG_stdin, seed = unknown...
-
Hi Lorenzo, I have created a standalone implementation of Ranlux++ written in C. It's based on code from ROOT project. I have directly compared the speed against xoshiro256** generator. The code is here. RESULT: xoshiro256** is faster by factor of 3x than Ranlux++ On Intel i7-8650U CPU, it takes 7.7 seconds to generate 1e9 64-bit numbers with Ranlux++ and only 2.6 seconds to generate 1e9 64-bit numbers with xoshiro256**. I hope this helps. Jirka
-
Hi Lorenzo, thanks for the notification! I have found the portable implementation: https://github.com/root-project/root/blob/ee0ba46eadb889c8a05274e1b7f5ea68c590b2ea/math/mathcore/src/ranluxpp/mulmod.h Function multiply9x9 to multiply two 576 bit numbers (stored as 9 numbers of 64 bits each) is rewritten from assembly to portable code. I will try to extract the code to create a standalone portable version of Ranlux++ and compare it to other RNGs. Jirka
-
I wanted to report that a new C++ implementation of Ranlux++ has been very recently presented by Jonas Hahnfeld, Lorenzo Moneta, see https://arxiv.org/abs/2106.02504 From what I can see from the paper their optimized C++ implementation is portable and can be about as fast as the x86 assembly one. They report a performance of about 9 ns/number both on an AMD Ryzen 9 3900 and on the Apple M1 using the Clang compiler (if I understand correctly "number" is a 64bit and they use only one core on each CPUs....
-
tylov modified a comment on discussion Open Discussion
I did some work on this in June, and created a github repository: https://github.com/tylov-fork/PractRand I mentioned it here: https://sourceforge.net/p/pracrand/discussion/366935/thread/86ce2d40a6/#c456 As said, it contains the full history. I created a new branch development which contains some bugfixes, including the one Cerian Knight mentioned. It also fixes the WIN32 bug with the input stream in RNG_test: The problem was not buffer size related as many have said, but that stdin was not set to...
-
I did some work on this in June, and created a github repository: https://github.com/tylov-fork/PractRand I mentioned it here: https://sourceforge.net/p/pracrand/discussion/366935/thread/86ce2d40a6/#c456 As said, it contains the full history. I created a new branch development which contains some bugfixes, including the one Cerian Knight mentioned. It also fixes the WIN32 bug with the input stream in RNG_test: The problem was not buffer size related as many have said, but that stdin was not set to...
-
I did some work on this in June, and created a github repository https://github.com/tylov-fork/PractRand. I mentioned it here: https://sourceforge.net/p/pracrand/discussion/366935/thread/86ce2d40a6/#c456 As said, it contains the full history. I created a new branch development which contains some bugfixes, including the one Cerian Knight mentioned. It also fixes the WIN32 bug with the input stream in RNG_test: The problem was not buffer size related as many have said, but that stdin was not set to...
-
Hi Lorenzo, thanks for sharing your opinion! I do agree with your criticisms, especially with the point about the assembly implementation and resulting portability problems. The code could be probably rewritten using AVX intrinsic functions to improve readability, but it will not help the portability of the code. I see this as a general issue with the AVX instructions - they are powerful, but not easy to use and creating portability issues. Recently, Linux Torvald has criticized the new Intel's AVX-512...
-
nsajko modified a comment on discussion Open Discussion
Just by looking at some GCC warnings, I'm 95% sure PractRand (0.94 + pre0.95) has some easily fixable but possibly quite serious bugs. I'm willing to contribute fixes, but it's really not clear what's the process for that. I'm a bit put off by the possibility that the bugs are already fixed in some unreleased version, because, as far as I understand, there is no development version available after pre0.95. Do you have something unreleased you're working on? How would you feel if I imported 0.94 and...
-
Just by looking at some GCC warnings, I'm 95% sure PractRand (0.94 + pre0.95) has some easily fixable but possibly quite serious bugs. I'm willing to contribute fixes, but it's really not clear what's the process for that. I'm a bit put off by the possibility that the bugs are already fixed in some unreleased version, because, as far as I understand, there is no development version available after pre0.95. Do you have something unreleased you're working on? Also, are there plans to switch to Git?...
-
Hello, In the header tools/MultithreadedTestManager.h, a member function called retire has volatile return type. I guess the intention was to prevent some compiler optimization? Whatever the intention was, it's not being served by having a volatile return value: that construction in the type signature has no meaning, i.e., the semantics are the same as if the volatile keyword was omitted. I.e., the compiler just ignores it. So you probably have a bug there somewhere. Also, AFAIK C++20 disallows having...
-
I can tell you my opinion on Ranlux++, although please note that I'm not at all an expert in the field. From a practical point of view, I think Ranlux++ has quite a few good things going for it. You already listed them, but to re-iterate: 1) It is a LCG generator using a very large 576-bit constant and a lot of decimation (skipping) to get rid of short-range correlations. The theory behind it is well-studied, both in general terms and for the specific RANLUX choice of constants. 2) It has been used...
-
Hello, I would like to ask your opinion on the new version of the RANLUX generator, called RANLUXPP. There are two papers on it: A revision of the subtract-with-borrow random number generators https://arxiv.org/pdf/1705.03123.pdf Review of High-Quality Random Number Generators https://arxiv.org/pdf/1903.01247.pdf RANLUX is a well-established generator in particle physics for Monte Carlo simulations. It's theoretically backed up by the theory of dynamical systems. The original RANLUX's main drawback...
-
Only Chris can answer for sure. While waiting for his feedback I can give some general considerations. I've never used Visual Studio, but it may just be that you compiled with 'debug' compiler flags on, which triggered a lot of warnings. In your file there are 70 lines labelled as 'messages' (which I think we can ignore), and 397 'warnings'. Of the warnings, about half (196) are of this type: warning C4244: 'return': conversion from 'PractRand::Uint64' to 'PractRand::Uint32', possible loss of data...
-
Georg Stroehlein posted a comment on discussion Open Discussion
Hi Lorenzo and everybody else, when loading the VS project file, which is thanksfully delivered within the v0.94 archive, into VSCE2019, I was asked whether I wanted to update the toolchain from v120 to v142. I answered yes. After that, I was able to build all programs as x64-release, but the amount of warnings thrown by VSCE2019 frightens me, because I cannot judge whether the computed results of the programs are compromised or not. I have attached a text file showing the entire output of VSCE2019...
-
I would like to bring to attention the following recent paper: Lama Sleem and Raphaël Couturier, TestU01 and Practrand: Tools for a randomness evaluation for famous multimedia ciphers, Multimedia Tools and Applications (2020)79:24075–24088 https://link.springer.com/article/10.1007/s11042-020-09108-w (unfortunately behind paywall) The authors use TestU01 and Practrand to test the implementations of several ciphers (block and stream). The ciphers analysed are the following (the library they come from,...
-
A. Augusto Alves Junior posted a comment on discussion Open Discussion
Thank you very much G. Jones, I will look into it right now and update the testing code. I will post back here the results. About the impact of the PRNG quality in the results, it is hard to say for sure, agree. Also, it would be harder to find out than just update the PRNG for a reliable one. It is plenty of choice around, with very good performances. Let's see...
-
G. Jones posted a comment on discussion Open Discussion
And here's the notes. I'll add that i suspect the prng is not all that good. Whether it's bad enough to invalidate the actual application is hard to know. Often even quite bad prngs can be useful, but not always. Hopefully in the rewrite of the application, there will be some thought to being able to replace the prng with minimal pain, so at least two different prngs can be tested to see how consistent results are. Best of luck.
-
I've done some hacks to your c++ code. I think the approach is slightly different to Lorenzo's and possibly a more useful way to convert double to 32 bit unsigned int. Unfortunately it is untested as i don't yet have a fortran compiler. Notes follow in the next comment. Ignore if you're happy with what you've already got.
-
Thank you very much Lorenzo. Your results just confirmed my suspicions. Ï will update my testing wrapper to perform the byte extraction in the way you did, and document well the whole thing, to recomend the core developers the adoption of a more reliable PRNG. Thank you very much.
-
BTW, I confirm that byte6 does fail PractRand at 256GB: rng=RNG_stdin, seed=unknown length= 256 gigabytes (2^38 bytes), time= 3601 seconds Test Name Raw Processed Evaluation BCFN(2+2,13-0,T) R= +37.5 p = 1.4e-19 FAIL ! [Low1/8]BCFN(2+0,13-0,T) R= +39.6 p = 1.0e-20 FAIL !! ...and 370 test result(s) without anomalies
-
Hello, I had a look, but please note that I'm no expect in such things and I may be doing something trivially wrong. First, I used prng_streamer with options -m from 0 to 2, and the otput stream I got is clearly non-random (it's sufficient to open, say, the first megabyte as a raw greyscale image to see lots of patterns in the data). Consequently, PractRand fails instantly for these streams. I haven't checked your source code, but it seems that you're extracting the random bits incorrectly. I wrote...
-
Thanks! I'll have a look at it during the weekend.
-
Hi Lorenzo, thank you very much. Can you access the repository below? https://gitlab.ikp.kit.edu/AAAlvesJr/C7PRNG It is a cmake project. Building: >> cd C7PRNG >> mkdir build >> cd build >> cmake ../ >> make You can use prng_streamer to run PractRand. Usage: /prng_streamer -s{0,1,2} -m{0,1,2}| /opt/practrand/RNG_test stdin Options: -s: sequence number: the generator is generating 3 sequences in chunks of 1024 numbers. -m: test mode. 0 [ naive conversion of double to uint64_t ] ; 1 [ test the higher...
-
Hi Lorenzo, thank you very much. Can you access the repository below? https://gitlab.ikp.kit.edu/AAAlvesJr/C7PRNG It is a cmake project. Building: >> cd C7PRNG >> mkdir build >> cd build >> cmake ../ >> make You can use prng_streamer to run PractRand. Usage: /prng_streamer -s{0,1,2} -m{0,1,2}| /opt/practrand/RNG_test stdin Options: -s: sequence number: the generator is generating 3 sequences in chunks of 1024 numbers. -m: test mode. 0 [ naive conversion of double to uint64_t ] ; 1 [ test the higher...
-
Let me guess: Pythia? If it passes bigcrush it shouldn't, I don't think, fail PractRand very quickly. Could you perhaps post the code (in Fortran and/or C++) used for the generator? The original generator by Marsaglia used, if I'm not mistaken, 32bit floating point numbers, which have a 24 bit mantissa. If your program generates doubles (64bit floats) then perhaps you're assuming its whole mantissa is random and not only 24 bits of it? If you can post the code (Fortran and/or C++) used for the g...
-
The version I am tested is part of a major, and quite legacy, simulation tool and was originaly coded in FORTRAN at CERNLIB. It produces doubles as output. The generator passes TestU01, but the amount of tested data there is relatively small, as you know. Basically, for each generated double x I do : uint64_t y; uint32_t z; memcpy( &y, &x, sizeof(double) ); z = (y>>20); //for the 32 higher random bits of the mantissa // or z=y; // for the 32 lower random bits of the mantissa then I stream out to...
-
The version I am tested is part of a major, and quite legacy, simulation tool and was originaly coded in FORTRAN at CERNLIB. It produces doubles as output. The generator passes TestU01, but the amount of tested data there is relatively small, as you know. Basically, for each generated double x I do : uint64_t y; uint32_t z; memcpy( &y, &x, sizeof(double) ); z = (x>>20); //for the 32 higher random bits of the mantissa // or z=x; // for the 32 lower random bits of the mantissa then I stream out to...
-
I think it is possible to test it, but you have to perform a few passages to produce a stream of random bits (which is what PractRand wants) from the mantissa of a 32-bit float. Perhaps you can create a 96-bit buffer in which you can put 4 24-bit mantissas; then you extract from the buffer 3 32-bit unsigned integers (there may be better ways of doing this): BTW, I found this implementation of the generator: http://paulbourke.net/miscellaneous/random/randomlib.c In any case, even if it passes all...
-
Hi Guys, First of all let me presents my contratulations for the very nice and usefull project. Here is my question: I am dealing with a legacy PRNG, the one described in the paper "George Marsaglia, Arif Zaman, Wai Wan Tsang - Toward a universal random number generator, Statistics & Probability Letters, Volume 9, Issue 1, 1990, Pages 35-39, https://doi.org/10.1016/0167-7152(90)90092-L" , which generates uniform doubles in the range [0. , 1. ]. Is it possible to test it using practrand ? If yes,...
-
Daniel Lehenbauer created ticket #15
SegFault on Linux/GCC due to missing return values
-
Confirmed. This effects any OS using a case-sensitive file system, which is the default for popular Linux distros. I submitted a fix to the GitHub mirror. You can view the diff here.
-
Hans posted a comment on discussion Open Discussion
Thanks, this works! rng_test stdin < encrypted.txt -tlmin 1KB
-
That probably means it ran out of input while reading from stdin. That's pretty normal. Realize that by default, PractRand tries to test 32 terabytes, and I very much doubt test.txt is 32 terabytes. Try making sure that test.txt is at least a few kilobytes long, then run PractRand with the command-line option "-tlmin 1kb" - that will tell PractRand to start displaying results after just 1 kilobyte.
-
That probably means it ran out of input while reading from stdin. That's pretty normal. Realize that by default, PractRand tries to test 32 terabytes, and very much doubt test.txt is 32 terabytes. Try making sure that test.txt is at least a few kilobytes long, then run PractRand with the command-line option "-tlmin 1kb" - that will tell PractRand to start displaying results after just 1 kilobyte.
-
Hello, when i use RNG_test stdin < test.txt i get the error "“error reading standard input”. I am using Windows 10. I have tested it with several versions (including 0.95 merge to 0.94). In earlier versions i dont get the error message, instead it crashes. Can someone help or maybe tell me what i have to patch in sources? Thanks!
-
You are mixing up the values and the log-base-2 of the values. And possibly the units too. A 32-bit xorshift would fail more aggressive testing at about 64 bits tested, or about 8 bytes. Written as powers of 2, that would be 2^6 bits or 2^3 bytes of output. PractRand can't even test that little data, its minimum test size is one kilobyte. Also, when PractRand finds bias after whatever number of kilobytes tested, that is an upper bound on the amount of data needed to show non-randomness. A more specialized...
-
Wayne Harris posted a comment on discussion Open Discussion
This makes sense. Thanks for the explanation.
-
Your language is a little beyond my currenty capacity for understanding. You're saying no, not having detected anything wrong with a sample of 2^15 bytes does not let us say that Xorshift is not nonrandom up to 2^15. I thought Xorshift 32 were 32 bits in internal state. So 2^15 is well below the internal state capacity. You're saying PractRand is deliberatly designed not to try to claim a generator as non-random consuming only roughly their state size. Then you give us two reasons for that. Am I...
-
Thanks very much! I was able to locate it.
-
Many guides for what to do with real-world statistical test results in the field are based upon the assumption that the test results come from crude chi-squared tests of small datasets that produce horrible p-value quality. In such cases, many p-value ranges end up being flatly impossible or have a very different likelyhood than an idealized model of p-values would suggest. TestU01 (and many other PRNG testers) on the other hand frequently produces p-values that are far closer to the idealized model....
-
If I restrict the sample sizes to 2^15 bytes, nothing against Xorshift 32 is found. Does it make sense to say that up to 2^15 bytes, Xorshift cannot be said to be nonrandom? No. Xorshift generators could be detected as non-random given only a few bits of output more than their state size. PractRand is deliberately designed to NOT do so, for two reasons. One reason is because PractRand attempts to keep the ratio of CPU cycles used to bytes tested relatively constant over the long term, and doing such...
-
Cerian Knight posted a comment on discussion Open Discussion
The short answer is that if you limit the statistical tests to those in PractRand with mostly default options, then 'yes', Xorshift cannot be said to be nonrandom up to 2^15 bytes. The point I was trying to make is that 'Xorshift cannot be said to be nonrandom up to 2^15 bytes' is true even if I run no randomness tests at all. This is as opposed to running all (easily available) randomness tests, which show Xorshift32 is not random up to 2^15 bytes.
-
For Windows, I typically already have (usually several version of free) Visual Studio installed, or just download and install the required runtime package. I've only just recently learned Linux and C over the last few years on my own for working with random numbers, as otherwise I am more competent on Windows using either Visual Basic or assembly language (so I probably should keep my opinions on Linux and C to myself).
-
A few critical points with your example (yes, I ramble): 1. To access the full power of PractRand in the sense you are looking for, in theory you should use additional command line switches. 2. The specific additional switches I use are '-tf 2 -te 1' (and 'stdin', instead of 'stdin32' might provide some additional benefit, but not sure about it with Xorshift). 3. However, doing so exposes issues with statistical calibration at ~64KB and lower. 4. Therefore, PractRand is not optimal for in-depth study...
-
TestU01: A C Library for Empirical Testing of Random Number Generators Page 5
-
If I restrict the sample sizes to 2^15 bytes, nothing against Xorshift 32 is found. Does it make sense to say that up to 2^15 bytes, Xorshift cannot be said to be nonrandom? C:\random>xorshift.exe | RNG_test.exe stdin32 -tlmax 32KB RNG_test using PractRand version 0.94 RNG = RNG_stdin32, seed = unknown test set = core, folding = standard (32 bit) rng=RNG_stdin32, seed=unknown length= 32 kilobytes (2^15 bytes), time= 0.1 seconds no anomalies in 34 test result(s)
-
Thank you, Cerian Knight. I found the binaries in 0.94 and I had to only download msvcr120.dll and msvcp120.dll to make them run. (It'd be nice to have those DLL included in the package, if Microsoft allows such thing.) It runs now just fine, so I'm good. For the record, I was also able to compile 0.94 just fine. Notice my command lines are not precisely those in the documentation. We don't need -lpthread during compilation, only during linking. Since I'm using GNU tools, I had to add -std=gnu++11...
-
Thank you for the info. Which documentation is that? I'm searching through User’s guide detailed version, User’s guide compact version, MyLib-C, ProbDist. I can't find this quote on any of them.
-
P-values in TestU01 (and PractRand) are non-standard, so 0.5 (on average) is most likely. Values very close to 1 are 'too uniform' (i.e. a potential indication of a 'low-discrepancy sequence' and/or a PRNG run near its full period). From the TestU01 documentation: "Classical statistical textbooks usually say that when applying a test of hypothesis, one must select beforehand a rejection area R whose probability under H0 equals the target test level (e.g., 0.05 or 0.01), and reject H0 if and only...
-
P-values in TestU01 are non-standard, so 0.5 (on average) is most likely. Values very close to 1 are 'too uniform' (i.e. a potential indication of a 'low-discrepancy sequence' and/or a PRNG run near its full period). From the TestU01 documentation: "Classical statistical textbooks usually say that when applying a test of hypothesis, one must select beforehand a rejection area R whose probability under H0 equals the target test level (e.g., 0.05 or 0.01), and reject H0 if and only if Y ∈ R. This procedure...
-
But a p-value close to 1 is not statistically unlikely. Quite the contrary. It is highly statiscally likely. It is telling us that that sample extracted (or one more atypical than it) has almost 100% probabily of ocurring. In other words, there is nothing unsual about that at all. (Or am I reading this whole thing incorrectly?)
-
TestU01 simply wants to draw your attention to anything statistically unlikely. I typically run the same PRNG on anywhere from a few dozen to a few thousand different seeds and perform meta-analysis of the set of results. In my experience, over hundreds of thousands of results, you should never see a p-value of less than 1.0e-08, or greater than 1 - 1.0e-08, from a good PRNG. If you do, then a single occurance (except perhaps, debatably, outside of perhaps 1.0e-15) is still not noteworthy unless...
-
I recommend compiling 0.94 first, since it should be fairly trouble free for .NET. Then try to merge pre0.95 into it, following some info here: https://sourceforge.net/p/pracrand/discussion/366935/thread/35c96c218d/ I actually run both GNU and Windows binaries of TestU01 (STDIN version compiled originally with Cygwin), PractRand and gjrand interchangably under WSL (sometimes piping output from a Windows exe PRNG source/graphical visualization tool to a GNU exe of one of those three).
-
I usually run PractRand on GNU systems, but I can see that it should run on Windows too. Perhaps it was meant to be run on Windows. Must I compile it or is there an executable somewhere? Thank you.
1 >