-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Random tweaks + ofUrn [needed in 12.1 for final of::random interface] #7736
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
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 |
@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! |
Seems good to me I ran tests and re-read your discussions all looks good! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be float in default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay! Thanks! Yeah it just becomes a weird oddity sometimes
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 toofUrn
.