Skip to content
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

Provide single PRNG or allow platfom adapters to define implementation? #1

Open
postspectacular opened this issue Sep 23, 2024 · 2 comments
Labels
RFC Request for comments

Comments

@postspectacular
Copy link
Member

Is it better to provide a single PRNG as part of the API and ignore any PRNG impls provided by platforms (current design)? If so, the API would require an init hook to obtain at least a seed value from the adapter (which always has to be sourced in a platform-specifc way).

Some benefits of a single PRNG would be: 1) de-duplication of effort and 2) potentially improved portability of variations between platforms using different PRNGs (which wouldn't matter anymore). On the other hand, different platforms will also use different seed values/mechanisms, but this would only apply to platforms/deployments outside the artist's control (i.e. if I publish pieces on my own website "platform", I can control and ensure the same seeds are used for variations I already created during development)

If opting for a single PRNG:

  • handling should be similar to time providers, i.e. supply a default implementation, but allow artists to override it
  • seed format of the PRNG must be standardized (e.g. using the 128 bit seeds (4x 32bit uints) currently used for SFC32/Xorshift128)
  • platform adapters would require a getSeed() function to obtain a standardized seed value
@postspectacular postspectacular added the RFC Request for comments label Sep 23, 2024
@robertoranon
Copy link

I have no strong opinion on this, but for whatever it's worth, in my artworks I most often use multiple PRNGs, e.g. one for colors, one for geometric shapes calculation, and so on (I typically have 4-5 of them). This makes it easier, when experimenting, to e.g. keep the colors in an output but alter the code that generates the shapes.
The different PNRGs are seeded from a "main" PRNG, so I guess my case can be still be framed as using a single PRNG ?

@postspectacular
Copy link
Member Author

Thank you, @robertoranon — I'm also doing the same, using several sub-PRNGs, all seeded by the main one at startup — and yeah, I'd still file this under "single PRNG"... Here, I was more thinking about portability between different platforms (and their different PRNGs algorithms) and aiming for reproducibility of pre-curated variations when switching platforms. Personally, I'm thinking that, if this reproducibility is an actual concern, this can be ensured using your own per-artwork PRNGs internally, but I'm also sure there're different points of view... :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request for comments
Projects
None yet
Development

No branches or pull requests

2 participants