swarm.random.sgml.reference.html

set for Swarm2.1是圣菲研究院的开发人员对Swarm的特性及其使用描述的最为完备的指南性文档。从这里可以获得最细致的平台说明。

><P
>A `split' generator is a long-period generator for
which we are able to split the period into arbitrary sub-periods,
which we can access quickly.  We then configure the generator as
having a number (A) of `virtual generators', each of which can address
a number (2^v) of sub-segments of length 2^w.  These parameters
(A,v,w) are user selectable when the generator is created.  (As an
example, for C4LCGXgen the default values are A=128, v=31, w=41.)  The
advantage is that the subsegments act as statistically independent
streams of random numbers.</P
></LI
><LI
><P
>In addition to the -getUnsignedSample method,
generators now also supply floating point output in the range
[0.0,1.0), in the form of these methods:

<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>   -(float)       getFloatSample;		// using 1 unsigned value
   -(double)      getThinDoubleSample;		// using 1 unsigned value
   -(double)      getDoubleSample;		// using 2 unsigned values
   -(long double) getLongDoubleSample;		// using 2 unsigned values</PRE
></TD
></TR
></TABLE
>

Note that the last method is not portable across architectures, since
the length of a long double varies between machines.</P
></LI
><LI
><P
>Generators may now be started with a single seed, *or*
with a vector of seeds whose length is generator dependent. (PMMLCG
requires 1 integer for a seed, while MT19937 needs 624 of
them.)</P
></LI
><LI
><P
>Generators now remember what seed values they were
started with. They also count how many variates they have delivered
(i.e., how many calls to -getUnsignedSample they have
serviced.)</P
></LI
><LI
><P
>There are a few arbitrary seed values, DEFAULTSEED,
DEFAULTSEED1, DEFAULTSEED2, DEFAULTSEED3, DEFAULTSEED4 defined. There
is also the value FIRSTSEED, which returns the value that the default
generator `randomGenerator' was started with.</P
></LI
><LI
><P
>The macro NEXTSEED will generate a deterministic
sequence of seed values, using and inline LCG and starting with
FIRSTSEED. There is the macro RANDOMSEED, which will be different
every time it is invoked because it depends on program time.  And
there is value STARTSEED, which will by default equal NEXTSEED, but
will instead be equal to RANDOMSEED if you start your program with the
<TT
CLASS="OPTION"
>--varyseed</TT
> or <TT
CLASS="OPTION"
>-s</TT
> command line
parameter.</P
></LI
><LI
><P
>The generators have gained a new creation method,
'+createWithDefaults: aZone', which creates the generator and
initializes it with STARTSEED. Split generators get default values for
A,v,w.</P
></LI
></UL
></P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Version 0.7: Changes since version 0.6. </B
><P
></P
><UL
><LI
><P
>The generator classes have changed names to where they
all end in '-gen'.  A simple search-and-replace in your code will get
you up and running again.(Or perhaps you'll want to try one of the new
generators?)</P
></LI
><LI
><P
>A bug in SWBgen was corrected. Code for ACG and SCG
was also changed.</P
></LI
><LI
><P
>The <TT
CLASS="FUNCTION"
>-verifySelf</TT
> method is
gone. Instead see the test program located in
<TT
CLASS="FILENAME"
>/random/testR0</TT
>. (Available in a separate tarball
at the SFI ftp site.)</P
></LI
><LI
><P
>The `getState:' method has been named `putStateInto:
(void *) buffer', and the `setState:' method is now `setStateFrom:
(void *) buffer'.  A quick search-and-replace fixes things in your
code.</P
></LI
><LI
><P
>Note: these methods have also changed somewhat, as has
the size of the data being saved. As a result, v. 0.7 generators will
refuse to `setStateFrom' data saved by v. 0.6
objects.</P
></LI
><LI
><P
>There should be fewer changes like this in the next
release.</P
></LI
></UL
></P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Testing Generators. </B
> Since v. 0.6 we have done some rudimentary statistical testing
of the implemented generators, using Marsaglia's Diehard tests and the
ENT tests.  The results of these tests are summarized in Generator
quality table (now found in the <A
HREF="http://www.swarm.org"
TARGET="_top"
><I
CLASS="CITETITLE"
>Swarm User Guide</I
></A
>), where test results as
well as period length, state size and execution times are listed. You
can use these data to select a generator that suits your
simulation. Some brief comments:

<P
></P
><OL
TYPE="a"
><LI
><P
> the tests show that old generators SCG and LCG are of
poor quality and should be avoided.</P
></LI
><LI
><P
> the lagged-Fibonacci based generators (ACG, SWB,
PSWB) all fail Diehard's `Birthday spacings test', for reasons having
to do with their lattice structure.  These generators are only
conditionally recommended.</P
></LI
><LI
><P
> The rest of the 32-bit generators (i.e. generators
that fill all 32 bits of an unsigned int) pass all tests, and are
recommended at this time. (Note that while a test may show that a
generator is bad, passing a number of tests does not prove that a
generator is good!)  </P
></LI
><LI
><P
> The 31-bit generators all fail the same set of
tests. Some of these cannot be passed by a generator whose output has
a `stuck' bit.  Until I clear up with Prof. Marsaglia how to interpret
these results, I believe all the 31-bit generators are in the
`recommended' category.</P
></LI
><LI
><P
>However, a cautionary note: while the PMMLCG
generators pass the tests, they have a very short period ( less than
2^31 ) and should only be used for `toy' simulations. You don't want
your generator(s) to `go around' and start repeating themselves
!</P
></LI
><LI
><P
>For what it's worth, Professor L'Ecuyer recommends his
own C4LCGX and C2MRG3 generators as well as Matsumoto's TT800 (the
monster MT19937 hadn't been released yet), and Prof. Marsaglia
recommends his own Multiply-With-Carry generators (MWCA, MWCB, C3MWC,
RWC2, RWC8="Mother").</P
></LI
></OL
></P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN13021"
>5.3. Implementation notes for Distributions</A
></H2
><DIV
CLASS="FORMALPARA"
><P
><B
>Version 0.8: Changes over version 0.75. </B
>No functional changes were made. Code was rearranged to conform
to create-phase protocol (CREATING-SETTING-USING) ordering.</P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Version 0.75: Changes over version 0.7. </B
>No functional changes were made.</P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Version 0.7: Improvements over version 0.6. </B
>
<P
></P
><UL
><LI
><P
>One new distribution class, BernoulliDist, has been
added. It returns binary values (yes/true/1) with a given probability
(while the old RandomBitDist has a fixed 50% probability, a fair coin
toss.)</P
></LI
><LI
><P
>Distributions now have a new create method,
'+createWithDefaults: aZone'.  This method creates the distribution
object, and also a new generator object for its exclusive use. Each
distribution class has a different default generator class
assigned. These generators are initialized with STARTSEED, which by
default equals the fixed value DEFAULTSEED, but will be equal to the
varying RANDOMSEED if you start your program with the command line
parameter <TT
CLASS="OPTION"
>--varyseed</TT
> or
<TT
CLASS="OPTION"
>-s</TT
>.</P
></LI
><LI
><P
>All distributions have code to interact with the new
`split' generators.</P
></LI
><LI
><P
>UniformIntegerDist and UniformUnsignedDist now allow
you to set parameter minValue equal to maxValue. In this case that
value is returned every time.</P
></LI
><LI
><P
>UniformDoubleDist also allows this, even if the set
[x,x) is mathematically suspect ...</P
></LI
><LI
><P
>NormalDist and LogNormalDist now allow you to specify
zero Variance, in which case the values returned are the Mean and
exp(Mean) respectively.</P
></LI
></UL
> &#13;</P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Version 0.7: Changes since version 0.6. </B
><P
></P
><UL
><LI
><P
>The distribution classes have changed names to where
they all end in `Dist'. A simple search-and-replace in your code will
get you back up and running.</P
></LI
><LI
><P
>The strong distinction between `frozen' and
`un-frozen' distribution objects in v. 0.6 has been softened
considerably. You may now set and reset the default parameters as
often as you wish, and you may make calls for variates with given
parameters even if different default parameters have been
set.</P
></LI
><LI
><P
>The generation of uniform(0,1) floating point values
has been moved from the distribution objects into the generator
objects.  Thus, if all you need is a uniform(0,1) double, you have no
need of a distribution but can get what you desire from a
generator.</P
></LI
><LI
><P
>Note that the generators fill the mantissa of a double
from two 32-bit unsigned values in a different manner from v. 0.6
distributions, so output will be a bit different in the new
version.</P
></LI
><LI
><P
>A bug in LogNormalDist has been
fixed.</P
></LI
><LI
><P
>The `getState:' method has been named `putStateInto:
(void *) buffer', and the `setState:' method is now `setStateFrom:
(void *) buffer. A quick search-and-replace fixes things in your
code.</P
></LI
><LI
><P
>But note: these methods have also changed somewhat, as
has the size of the data being saved. As a result, v. 0.7
distributions will refuse to `setStateFrom' data saved by v. 0.6
objects.</P
></LI
></UL
>&#13;</P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Utility Objects Provided. </B
>The following objects have been defined in
<TT
CLASS="FILENAME"
>random/random.m</TT
>.  They may be accessed and used
from anywhere in your program.

<TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>&#13;id &#60;SimpleRandomGenerator&#62;   randomGenerator;
id &#60;UniformIntegerDist&#62;      uniformIntRand;
id &#60;UniformUnsignedDist&#62;     uniformUnsRand;
id &#60;UniformDoubleDist&#62;       uniformDblRand;</PRE
></TD
></TR
></TABLE
>

The 3 distribution objects all draw their random numbers from the
MT19937 generator, which has a period of 2^19937 (10^6001) and is
quite fast.</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN13070"
>5.4. Programming yet to do</A
></H2
><P
>Like many Open Source projects, this random-number library
        is a work in process. Further developments still on the to-do
        list are detailed below.
      </P
><P
>The following changes and additions are contemplated for the
next release of Random for Swarm (though I don't promise they'll all
make it in -- nor when that next release will be):

<P
></P
><OL
TYPE="a"
><LI
><P
>ADD a few more generators. It's good to have many
different types of generators, so you can test your model's results
with different generators and ensure that the results aren't artifacts
of the generator used. And people seem to insist on inventing new,
better ones with longer periods!</P
></LI
><LI
><P
>ADD more distributions. NOTE: if you have any strong
opinions about what distributions or generators need to be added,
please e-mail me!</P
></LI
><LI
><P
>TEST the generators, using Marsaglia's Diehard
battery, or L'Ecuyer's tests when/if those become available. This will
allow us (a) to make a choice between the implemented generators on
the basis of their statistical quality, (b) to decide what old and bad
generators to remove, and (c) to detect any bugs in my
implementation.</P
></LI
><LI
><P
>TEST the distributions, to make sure they actually
put out numbers according to the probability distribution and
parameters used.</P
></LI
><LI
><P
>ELIMINATE 'bad' old generators on the basis of
statistical tests</P
></LI
><LI
><P
>RETAIN PMMLCG as the only short-period generator, for
convenience</P
></LI
><LI
><P
>ADD an 'empirical' distribution, whose f is defined
by a set of user- supplied data</P
></LI
><LI
><P
>IMPLEMENT a version of getState/setState that is
portable across machine architectures, so that simulations may be
moved to or duplicated on other machines. (The problem: integers and
doubles are stored in different byte orders on different
systems.)</P