Overview

Seeding in SystemML/BRAHMS is described, here. A seed can be either a vector of one or more non-zero UINT32 values, a scalar UINT32 zero (specifying non-deterministic, use the clock or some such to try and randomize), or absent (unspecified). A separate seed must be obtained for each seeded item (i.e. for each individual generator within a Process) through a call to getRandomSeed() (or by firing ENGINE_EVENT_GET_RANDOM_SEED). The remainder of this document describes how BRAHMS chooses the seed to return to the component, according to the default seeding procedure. Alternative procedures are likely to be added, in future.

Seed Sources

Each Process is assigned a seed source from the following possibilities. First, a non-zero seed may be specified for the Process in the SystemML file. All elements must be non-zero, and its value is used directly as a repeatable seed source specific to the Process. Second, a scalar zero seed may be specified for the Process in the SystemML file. In this case, a non-repeatable seed source is associated with the Process. Third, a seed may be specified for the Execution in the Execution File. It must be scalar, be between 1 and 0x7FFFFFFF, and should (generally) be a smallish integer. Any Process that does not specify its own seed is associated with a repeatable seed source specific to the Process with its initial value based on the specified value and the index of the Process in the System (the initial value is always at least 0x80000000).

Each call to getRandomSeed() from within a Process generates a new seed from the seed source associated with the Process. Below, we describe how each type of seed source generates subsequent seeds.

Non-repeatable Source

This source returns a seed which is non-repeatable (generated from RDTSC). Each element can take any value except zero. No special effort is made to control the value beyond this.

Repeatable source

A repeatable source will return its own value, and then increment that value. If more elements are requested than are available, the seed is padded with the value 0xAAAAAAAA. Only the first element is incremented, and overflow raises an error. Overflow occurs if the first element increments to a value of zero. It is unlikely to be an issue, but you may want to vary the value of MinUniqueSeedsPerProcess for some very extreme systems where unique seeding is required.

Notes

Using Seeds (System)

To begin with, a system you build will have no explicit seeds anywhere, and every process will be passed non-repeatable seeds.

To simulate this non-deterministic system deterministically, the user may set the Execution File seed to a non-zero value. This will generate an entirely repeatable execution, unless any individual processes specify non-repeatable seeds.

To render the non-deterministic system, or parts of it, deterministic, the author may choose seeds for individual processes. These can then not be overridden by the Execution File seed.

To summarise, the general idea is that you seed Processes explicitly only when it is required that they produce identical output on all executions. The user of your System (even if that's you) can then generate repeatable or non-repeatable executions as required.

Using Seeds (Process)

Each seed required must be obtained through a separate call to getRandomSeed(). The Process should not generate its own seeds based on one seed returned by the framework, nor by any other means.