*) build and install the test suite (./configure, make, install) http://www.iro.umontreal.ca/~simardr/testu01/install.html *) set paths (<install directory> likely is /usr/local, and maybe this isn't necessary...?) export LD_LIBRARY_PATH=<install directory>/lib:${LD_LIBRARY_PATH} export LIBRARY_PATH=<install directory>/lib:${LIBRARY_PATH} export C_INCLUDE_PATH=<install directory>/include:${C_INCLUDE_PATH} *) copy Allin's instructions into a text file called "Makefile" *) copy Allin's .c file side by side with the Makefile *) in this directory, type 'make' in a shell -- you should get an executable file 'glibtest' However, when I run './glibtest' (glibtest built without error) I get the error: ./glibtest: error while loading shared libraries: libtestu01.so.0: cannot open shared object file: No such file or directory ...even though I had previously installed testu01?? BTW, I'm not an expert but it seems to me that it would be a waste if we all run this in parallel on the same platform (Linux on Core2Duo). If any parallel effort is done, it may be more useful to do it on various platforms and/or hardware, like Mac, or AMD, or whatever. thanks, sven Gordon Hughes schrieb:

On Sun, 27 Dec 2009, Sven Schreiber wrote in http://lists.wfu.edu/pipermail/gretl-devel/2009-December/002356.html [etc.] These instructions are perfectly correct. sudo ldconfig However, people might hold off for a bit with the crush tests. I think I now see what's going on. I'm no expert on RNGs, but here goes... 1) The main speed advantage from ziggurat is that (in the original Marsaglia/Tsang version) it requires the generation of only one random 32-bit integer per normal sample, where Box-Muller requires two. 2) However, Doornik points out that there's a problem with this, which emerges if you want to generate normally distributed "doubles" (64-bit floating point values -- the original ziggurat generated 32-bit "floats"). The trouble is that if you use just one set of 32 bits to select the ziggurat box or level and for the uniform value to be tested for acceptance at that level, you get a certain sort of subtle dependence, and the symptom is that the normal RNG fails Knuth's collisions test (on the regular crush suite as well as big crush). 3) I took Jochen Voss's ziggurat code and adapted it for gretl, and it passed all the tests. So at first I thought we'd somehow got around Doornik's problem (maybe by using a better RNG for the initial uniform input). 4) But then I took a closer look at the Voss code, and I see that it dodges the dependence problem by a means that Doornik mentions but does not recommend. Namely, from the initial 32-bit input it uses: 7 bits for the ziggurat level 1 bit for the sign 24 bits for the value to be tested There's no dependence problem because Voss uses non-overlapping bits for the box selector and the test value (and so one can quite confidently predict that this generator will pass the collisions test), but the drawback is that one can then generate "only" about 30 million distinct normal values. 5) To get better coverage of the real line one can use one and a quarter random ints per normal draw. For example, one can use 7 bits for selecting a box, one for the sign, and 30 for the test value, to get about 10^9 distinct normal values (with 2 bits of "wastage"). I've now implemented this in gretl and I'm running the crush suite right now. If it passes (in principle it should, but I might have screwed something up in regard to the quarter-ints), I'll commit it to CVS and then people can try attacking it with big crush. Allin.

Allin Cottrell schrieb: old result gretl 1.8.6cvs: loop ca. 2.6 seconds vectorized ca. 2.0 seconds new result gretl 1.8.6cvs w/ modified ziggurat: loop ca. 1.6 seconds vectorized ca. 0.8 seconds (of course the precision of the timing decreases the less time it takes) I think this is a remarkable change. The vectorized speed is now on par with Ox (the above results weren't for gretlcli). What's more (assuming that the new method also passes Big Crush), the process of Allin incorporating the ziggurat method was lightning-fast -- Alan Isaac, if you're still on the NumPy list maybe Allin's implementation could be interesting for them. cheers, sven