Random tweaks + ofUrn [needed in 12.1 for final of::random interface]

[artificiel]

Some tweaks to the random distributions interface, plus an ofUrn class that wraps a container implementing Sampling Without Replacement with a shuffling logic, with repeating or non-repeating phase edges. (got a bit deep in the templating but it makes it flexible you can "urn" pretty much anything you throw at it that would fit in a std container).

What problem does ofUrn solve: you have a pool of assets that you want to randomly access and deplete without repetitions before starting over. so in essence a "auto-self-shuffling" container that does not repeat it's values until emptied. there are some added subtleties like preventing the first item of a freshly refilled urn being the same as the last of the previous (which deviates from a proper Sampling Without Replacement, but in general the intent with an urn is to avoid repetitions), and also some methods to query the Urn state, and <optional>-based returns to handle things more monadically if you need to be informed of the urn auto-refill occurrences. The Urn can also be made not to auto-refill, etc.

There are some considerations regarding performance with large objects; iterator-based optimisation opportunities are noted but passing references or pointers instead of large objects is encouraged. in any case it's an implementation detail; the interface would stay the same.

implemented as of::urn and aliased to ofUrn.

[danoli3]

I like the idea as long as the second reshuffle of the urn can be still tied to that initial seed so it can be replicated even though subsequent shuffles are new vs the old pool

Similar concept to some MerseenseTwisters I made back in the day when no one knew what Ray Tracing meant except 3d people XD

[artificiel]

@danoli3 just to be sure it understand: you mean that you would want the urn reshuffling to be determinist in "parallel" to other random action/functions? (so I you have 10 urns, they all can have specific seeds and generate their own independent yet deterministic randomness?)

or just that you wish the urn to be tied to a (potentially) deterministic gen?

as of now: there is a single (thread safe) OF random engine which "customers" (for lack of a better term) query for randomness; each query advances the generator a step. since 12.0 ofRandom maps to uniform_distribution, which queries and advances the central engine (and other distributions are available).

by default at ofApp init, the seed is generated with random_device; manually providing a specific seed will produce deterministic results. the ofUrn proposal makes use of std::shuffle which drinks at the same randomness fountain, advancing the generator too.

so if a seed is provided, ofUrn will produce a deterministic sequence. however if other ofRandom calls are thrown in, they will get factored in and (deterministically) affect the next sequence. if the random calls (ofUrn, uniform or other) are themselves in a deterministic order, the results will be deterministic too.

let me know if that seems good to you!