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.

[robertoranon]

These are the two scenarios I work with:

• the platform is responsible for / needs to provide a seed for the artwork (like fxhash, artblocks). The adapter provides the prng property to abstract this. In turn, this provides a rnd function and a string seed, which you say is 'for information purposes only' (I understand due to the different seed / types as discussed above? but assuming 'full' portability is not needed, this could be used somehow?). In this case, what would be the recommended way to work with multiple PRNGs? Use rnd to generate a few float and convert them to seeds for the PRNGs?
• the platform does not provide a seed, but provides parameter values that the artwork uses for customization. The artwork can use the genapi PRNG (GenArtAPI.random), either with random seed or fixed seed (like in the layer, the seed is fixed, right?)
  Am I missing something?
  Thanks!

[postspectacular]

Hi @robertoranon — sorry, only managing to catch up with this now (and also just realizing I hadn't pushed my PRNG updates from a week ago)

I think your summary of the two scenarios is correct, or at least very much how I see it too. I've been meaning to add more details about the expected randomization logic to the readme, and I will try to do so asap.

In short (and including the recent changes done) this is a top level overview:

• When the platform adapter initializes (prior to the artwork), it pre-configures a PRNG instance (by whatever means), which then can be later accessed via $genart.random.
• If the platform does not use the concept of seed params (or meta params), it still has to provide a random one (by whatever means) and use it to seed the PRNG. The contract of PRNGs used by $genart.random is that they're both seedable and resettable. The contract also means, the PRNG has to be ready to use before the artwork accesses/uses it.
• The recent changes to PRNG logic were about making it easier to create & use multiple PRNG instances and to decouple the seed getter from the PRNG interface:
  • The main random seed can now be accessed via $genart.seed (previously $genart.random.seed)
  • I've added PRNG.copy() to allow creating a standalone new PRNG instance seeded with the current state of the parent PRNG
  • The SFC32 impl is now a class

To answer your question about creating multiple PRNGs, you can now (once I've released the new version) do that easily like so:

// optionally reset to seed state
$genart.random.reset();

// create 2 copies (each with separate state, but seeded with current parent state)
const rnd2 = $genart.random.copy();
const rnd3 = $genart.random.copy();

If you want to create an instance with a custom seed, use the builtin SFC32 class directly:

const myRND = new $genart.prng.SFC32([
  0xdecafbad,
  0xace0fba5e,
  0xcafed00d,
  0xf0cacc1a,
]);

As for the artwork param initialization logic:

Each param spec can define a default value. If it's not given (by the artist), then GenArtAPI will use the PRNG to choose a random default with the param's configured ranges/constraints. The effects of this behavior are:

• Ensure each param has a valid value when $genart.setParams() returns
• Reduce boilerplate to require artist producing (valid) randomized default values as part of the param specs
• Determinism is guaranteed and solely dependent on platform provided seed. Again, if the platform doesn't use (or currently provide) a hardcoded seed[1], then this can be used for rapid exploration of randomized versions (in which case you could use $genart.seed for information)
• Make param preset storage more compact by only having to store manually configured/customized params
• Each param has a ParamState which can be queried by both the artwork and editor tooling

Hope this makes more sense now! Happy to re-open this issue if you feel this needs more changes/discussion...

[postspectacular]

@robertoranon Btw. the recent changes I mentioned above are these two commits:

• cfb5acf
• a55ad86

[robertoranon]

Ok, this makes a lot of sense, and the helpers for multiple PRNGs are very useful.
Also related, is this PRNG implementation in any way compatible with / interoperable with the random utility functions, such as pick, weighted, ... defined in thi.ng/umbrella?

[postspectacular]

Thank you @robertoranon! :) If you want to use the genart random function with thi.ng/random (and all the supporting tooling) you can do the following:

import { WrappedRandom } from "@thi.ng/random";

const RND = new WrappedRandom($genart.random.rnd);

Hth! :)