pf_random_fill_draws Interface

public interface pf_random_fill_draws

Fills v with consecutive values of one stream, starting at draw (default 1).

v is a rank-1 real(real64) or real(real32) array, intent(out); i is integer(int32) or integer(int64); seed and draw are integer(int64). The values are exactly what the matching scalar draws would give at those positions, so a prefix is a prefix: v(1:3) filled alone equals the first three of v(1:6). A zero-sized v is a defined no-op.

Precondition on the draw axis: draw + size(v) - 1 must not exceed huge(int64). The last element's position has to be representable, because there is no value at a position that cannot be named -- a fill that runs past the end is asking for draws that do not exist, and it silently receives wrapped ones. Everything up to and including the boundary is exact: a fill whose final position is huge(int64) itself is correct, and is tested. The scalar entry points have no such limit, since every representable draw is a valid one.

An INTEGER v takes two further required arguments, lo and hi, which share v's kind -- call pf_random_fill_draws(seed, i, v, lo, hi [, draw]). Element k is then exactly pf_random_int_at(seed, i, lo, hi, draw+k-1), the same identity the real forms have with pf_random_at. The specifics are distinguishable on v's type alone, so the generic resolves without ambiguity, and lo > hi is swapped rather than refused, exactly as in the scalar draw.

The integer form amortises much as real64 does: an integer draw has stride 2, so consecutive draws pair up two to a block and the fill enciphers once for each pair. Measured on machine B (gfortran 15.2.1, -O3 -funroll-loops, 4M values, best of three alternating rounds against the committed /v1 build, with the real64 fill flat at 8.66-8.69 ns as a cross-build control): 25.21-25.32 ns per value before, 15.74-15.76 after, 1.61x. It was not always so -- see pf_random_int_at's own note on the stride change that made it possible.

Module Procedures