Simplify the construction of simple random numbers

[buddha314]

In chatting with bHarsh, I learned that Chapel is designed to preserve a random sequence in forall loops. (Don't ask me to go to deep.) However, a simple coin flip is pretty important. In Python, one can do

>>> import random
>>> random.random()
0.5547507267722159

Perhaps we can have two easier functions, one that is consistent across forall loops and one that is seeded locally. Maybe

var x = prandom()  // Get the same sequence in each forall
var y = lrandom()  // A globally seeded random sequence, will not be consistent across tasks.

The different names could encourage careful usage.

[ben-albrecht]

Implementation detail: I think this would involve instantiating a default RandomStream in the Random module, and providing helper functions called random() or lrandom() to get their next values.

Design detail: RandomStreams are instantiated with a type. What types would be supported by default? real (0.0-1.0) seems like a safe choice. Maybe bounded ints too?

[mppf]

I'll note that RandomStreams don't have to use a type. E.g. with PCGRandomStream, there is not a problem getting random values for different types with each call.

I believe we shied away from having a global RandomStream in the past because it might not be as clear that there is a shared stream when many tasks use it. OTOH, a top-level global RandomStream created by the user is subject to the same issues.

Lastly, the use-case that brought this up is a program that generates a single random value. I'm suspicious of using time to seed an RNG and extract one value - seems like we're just using munged time. Likewise, in a distributed run, if the nodes all have their clocks set exactly, might we get the same values from different random streams on different nodes? For these reasons I think we should change the default seed to use /dev/urandom on Linux when it is available.

[nspark]

This was why I wanted a module-level deinit() function that could free the module-level "convenience feature" RandomStream object.

[bradcray]

Hi Nick -- Just to make sure we're on the same page, you remember that we have module-level deinit() now, right? (I couldn't tell from the verb tense above).

[nspark]

@bradcray Yes, I just never got around to writing such a convenience random function. It's feature-freeze today, right? 😉

[mppf]

Note that there is a fair amount of discussion for the design of this in #7382.

[vasslitvinov]

See also #12540