• Saving and restoring engine state to file with user-supplied name.
  RanluxEngine e;
e.saveStatus ( "myFile.conf" );
e.restoreStatus ( "yourFile.conf" );

• Engine state stream output via << and input via >> . There are also constructors accepting an istream to determine the state.
  RanluxEngine e;
cin >> e;
cout << e;
RanLuxEngine e2 ( cin );


• The flat() methods in all added engines supply double precision numbers random out to the last bit. If the underlying engine works with 32-bit numbers, this requires a bit of extra work. We will provide conversion constructors for each engine, which can be used as in:

  DualRand e;
  double x; float f; unsigned int u;
  x = double(e);        // Exactly equivalent to x = e.flat();
  f = float(e);         // Equivalent to f = e.flat(); 
                        // but somewhat faster
  u = unsigned int(e);  // Equivalient to u=pow(2.0, 32)*e.flat() 
                        // but supplies the 32-bits obtained from
                        // the algorithm kernel, without the "middleman"
  

  A shorter syntax will also work, but is disparaged because it looks too mysterious:

  x = e;                // Will come out x = double(e);
  f = e;                // Will come out f = float(e);
  u = e;                // Will come out f = unsigned int(e);
  

  For consistency, the double, float and unsigned int operators are also be provided for the original engines, but these save no time.

DualRand

A new random engine, implementing one which is in wide use in the Lattice Gauge Monte Carlo community. It is a combination of a (127,97) Tausworthe shift register generator and ordinary 32-bit integer congruence. This passes the statistical tests in the Diehard suite, and is rather fast. It also has the property that two instances based on different seeds will give truly different streams, and not two separated segments of the same long stream.

Ranshi

A huge-state (2K bytes) generator based on F. Gutbrod's method of that same name. It repeatedly simulates throwing spinning balls onto a large collection of other spinning balls. One instance of Ranshi uses as a state one 32-bit "red ball" and 512 32-bit "black ball" spins. Techniques to avoid "trap" sequences are employed. Though the properties of this process have not been studied with any rigor, the huge state lends confidence in a good random sequence of long period. Despite the huge state, the time taken to generate a single random is excellent.

Ranlux64

A 64-bit variant of the Ranlux engine, again from Europe. This (along with all the ZOOM-supplied additional engines) supplies doubles which are random out to all 53 bits of mantissa, rather than just 32 as the original Ranlux does.

MTwist

The Mersenne Twister engine. This is a huge-state (~2.5 Kbytes) engine which has mathematically proven outstanding randomness properties and a period of 2**19,937 -1. Our implementation is from the algorithm in the paper; there is a culture on the web page of speed improvements but it is rather fast as it is, and we wanted as few risks of incorrectness as possible. This is probably the best huge-state engine available.

TripleRand

is a combination of the DualRand and the Hurd288 engines, with a period of over 2**400. This is intended as a small-state (60 bytes) reasonably fast "mother of all generators" for applications that are fairly paranoid. The Hurd288 engine implements a set of linearly interconnected shift register engines, based on the paper by William Hurd (not to be confused with GNU Hurd) in IEEE Transactions on Computers, C23 No. 2 page 146. This method is claimed to remove some unsatisfactory properties in the Tausworthe methods, stemming from the latter using trinomial primitive polynomials. We implement 160 and 288 bit instances, based on lines 9 and 10 of table I in that paper.

Corrections

• When engines were constructed, they were supposed to be given zero-terminated arrays of seed numbers as arguments. They were not, and in the case of RanLuxEngine this made a difference. In principle, this could lead to access violations; in typical use, the only effect would be that two identically seeded distributions would after a short while begin to diverge. This bug has been fixed, for all the distribution classes.

• The previous behavior of default constructors of random engines was such that if the user instantiated two intances of the same engine class using the default constructor each time, the sequences obtained would be identical. This is very trappy, and contradicts the most probable purpose of using this syntax. We now provide a different starting state each time. The user can get two matching sequences by explicitly supplying a specific seed, or by copying the engine object itself.

Validation and Extensions in Progress

• Default constructors will be provided for each of the distributions. These will conform to the following semantics: When a distribution is instantiated without specifying a specific engine, a new instance of a good random engine will be constructed, and will be owned only by the new distribution instance.

• Copy constructors and assignment operators will be provided for each distribution. The semantics for what engine is used when copying a distribution are as yet undecided. The three possibilities are:
  1. A clone of the same class of engine as used in the original distribution is instantiated and associated with the copy distribution. Thus the original and the copy distributions will have two completely independent streams.
  2. The copy distribution will share the same engine as the original. Thus firing either will advance the state of the other.
  3. A copy of the engine associated with the original will be made and associated with the copy distribution. Thus the distribution and its copy will fire identical streams of randoms.
  We are leaning toward the first of these possibilities. we welcome comments as to which choice people feel is most useful.

• Distributions for fluctuation of ionization energy loss:
  1. Landau distribution.
  2. Vavilov distribution, an approximation-free version of the Landau distribution with energy cutoff.
     This version will be quicker than the CERNLIB versions of Vavilov.
  3. Vavilov distribution corrected for spin-1/2 particles.

RanUniEngine

Another engine in use in the Lattice Gauge community. This comes from Marsaglia, and appears to be a lagged addition Fibonacci, added mod 1 to a simple c*d mod m. Since the set of other engines do not include a lagged Fibonacci, we will likely incorporate this one.

The following engines are also logical candidates for inclusion but we presently do not plan to provide them:

Ran2 from Numerical recipes, which is related to Ranecu.

Ran4 from Numerical recipes, which is related to the DES encryption standard.

GFSR, a 4-tap feedback shift register discussed by R. Ziff in Computers in Physics, July 1998.

There have been problems in the past understanding the results of the DIEHARD tests.

There is work in progress to:

• put this Marsaglia suite into clear C++;
• correct a suspected flaw in the Minimum Distance test, possibly introduced in the course of going from the original Fortran through f2c;
• add a couple of other tests which would have been impractical before the available computing power was at today's level.