Provide single PRNG or allow platfom adapters to define implementation?

[postspectacular]

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

[robertoranon]

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]

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... :)

[postspectacular]

Having implemented several platform adapters by now, I'm opting for the following approach:

• the @genart-api/core package will only provide the sfc32 PRNG impl (most widely used and very good quality)
• all current platform adapters are making use of this implementation
• removing xorshift128() and xsadd() impls from core API to avoid bloat (will update readme to point people to existing 3rd party implementations if they wish to rather use those, but out of scope of this project now)

The larger cross-platform reproducibility issue (i.e. when switching from one platform/adapter to another) is actually not easily solvable, since different platforms use different seed types/formats. So even if the actual PRNG implementation is the same in each adapter, the different seed formats are primary source for non-reproducibility.

The impact of this in practice is highly project dependent, and in worst case scenario means that existing variations have to be manually replicated, or artworks simply have to be created in such a way that they specifically declare a seed param (alongside other params) and then only use this seed value with their own PRNG derived from that (rather than using the platform adapter's PRNG)... Again, I'd consider this out of scope for this project here.