KatolaZ writes on Thu, 15 Mar 2018 23:19:42 +0000:

>> my biggest frustration was not being able of finding a way to
>> implement a 2D random walk in postscript that would show a different
>> trajectory every time you open it :D (the only problem there is the
>> seed).

This is getting off the topic in the subject line, but here are some
possibly helpful comments.

The PostScript virtual machine does a good job of isolating the
program (and programmers) from the underlying hardware, so this
does not appear to be an easy task.

This is a general problem with random number generation: some
applications need random, but reproducible, sequences (e.g.,
debugging, repeatable science, ....), while others would like to have
a random sequence that is different on every run (simulations,
selections, ...).

Most generators offer the possibility of setting the state,
which might be as simple as a single integer: different
states produce different sequences:

    GS>1 srand 5 { rand } repeat pstack clear
    1144108930
    984943658
    1622650073
    282475249
    16807

    [same output, no matter how many times you run it]

    GS>2 srand 5 { rand } repeat pstack clear
    140734213
    1969887316
    1097816499
    564950498
    33614

    [different output, because of differing starting seed]

    GS>33614 srand 5 { rand } repeat pstack clear
    940422544
    140734213
    1969887316
    1097816499
    564950498

    [demonstrating that the output of rand is just the next value
    starting from the current seed]

In normal programming languages, you may be able to generate a
likely-unique seed by combining (typically with an XOR bit operation,
which produces 0's and 1's with equal probability) data such as the
output of a high-resolution timer, process ID, user/group ID, ....

On many Unix-family operating systems, you can also get (almost truly)
random bytes by reading /dev/urandom or /dev/random. However, be
careful, because the latter is often implemented to block until
sufficient randomness is available in the kernel entropy pool, and
that could even take hours or days on a quiescent system. Thus,
/dev/urandom is safest, if you have it, and quite satisfactory for
getting different seeds for each simulation run.

In PostScript, I don't readily find any built-in operators that could
give a result that differs on every run, so you probably have to
inject suitable arguments for srand from outside sources. PostScript
can read data from files, so you could have a large file of seeds, and
read a new seed for each simulation.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@???  -
- 155 S 1400 E RM 233                       beebe@???  beebe@??? -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------