# -*- org -*-

#+CATEGORY: rng

* gfsr: for consistency (Charles A. Wemple).  Make this change in 2.0

 127a142

>   state->nd = i-1;

133,134c148,149

<   for (i=0; i<32; ++i) {

<       int k=7+i*3;

---

>   for (i=0; i<32; i++) {

>       int k=7*i+3;

141d155

<   state->nd = i;

* Sort out "const" in prototypes, it looks odd since there are consts

for many functions which modify the state.  (Applies to both qrng and rng)

* New 64 bit generators in "Tables of 64-bit Mersenne Twisters",

Takuji Nishimura, ACM Transactions on Modeling and Computer

Simulation, Volumen 10, No 4, October 2000, p 348--357

* Need to run tests over the space of seeds, in addition to serial

tests (DIEHARD) for the default seed.  The congruences used for

seeding will give poor initial vectors for some seed values, e.g. 2^n.

Improve the seeding procedure by using a high-quality generator

(e.g. hash functions, md5 or sha) to generate the initial vectors.

Even if this is moderately expensive it is worthwhile since the

seeding is usually a one-off cost at program initialization, and the

results of all subsequent calls to the generator depend on it.  The

GSFR4 generator is particularly likely to benefit from this procedure.

* Add SWNS generator Phys.Rev.E 50 (2) p. 1607-1615 (1994), Phys.Rev.E

60 (6), p.7626-7628 (1999)

* Add get_array type methods which can provide optimized versions of

each function (?). We should offer the possibility of eliminating

function call overhead -- there are various possible ways to implement

it.

* Add ISAAC generator (??)

* Add (A)RC4 and hash based random number generators MD5, SHA.  This

should give crypto quality randomness, and guarantee different

sequences for each seed. Make the state (seed, count) where count

increments on each call of the generator.  Implement count as a big

integer stored in separate unsigned integers so that the period is

sufficiently long (e.g. 2^64 or 2^96). The generator would return

HASH(seed, count) on each call.

* Check that RANLXS will work on machines with non-standard width of

float/dbl (original has checks for DBL_MANT_DIG ..)

* mention more clearly why not all Cokus used (or recheck MT pages for

improvements)

* run the DIEHARD tests on all the generators, especially the ones we

are listing as "Simulation Quality" -- some of those are a bit old and

might fail one or two diehard tests.

* Add  NAG,       missing, gave up! 

       CDC 48-bit missing 

* Check out the bug fix to mrand48 that was made in glibc2, pr757

* Check out  the following paper,

    On the anomaly of ran1() in Monte Carlo pricing of financial

    derivatives; Akira Tajima , Syoiti Ninomiya , and Shu Tezuka ; Winter

    simulation , 1996, Page 360, from ACM

* The following papers have been published, I think we refer to them

(or could do),

    Pierre L'Ecuyer, "Tables of Linear Congruential Generators of different

    size and good lattice structure", Mathematics of Computation, Vol 68,

    No 225, Jan 1999, p249-260

    Pierre L'Ecuyer, "Tables of Maximally equidistributed combined LSFR

    generators", ibid, p261-270

* Look at this paper: I. Vattulainen, "Framework for testing random numbers

  in parallel calculations", Phys. Rev. E, 59, 6, June 1999, p7200

----------------------------------------------------------------------

DONE

x1. Improve the seeding for routines that use the LCG seed generator.

It can only generate 130,000 different initial states. We should

change it to provide 2^31 different initial states (this will also

prevent the high bits being zero). DONE - we now use a 32-bit

generator.

x8. Get the macros from the faster MT19937 generator and use them. We

need to make MT be the fastest of the simulation quality generators if

it is the default. DONE. It didn't improve the speed on other

platforms, so I just used the tricks which also worked on the pentium

(e.g. changing mag[x&1] to x&1 ? mag[1] : mag[0])