Is it possible to use Peroxide without `rand`/`rand_distr`?

[TimeTravelPenguin]

I am trying to work on writing a plugin for Typst. Due to the way they isolate plugins, IO is not possible. As such, when I initially attempt to use Peroxide, I cannot due to the use of rand/rand-distr packages is naturally stateful.

Is it at all currently possible to work around this? Would it be possible (or reasonable) to request a feature flag to disable rand functionality?

Apologies for not being more specific. In all honesty, I am not entirely familiar with how the technical details work.

[Axect]

This is still on the table but nontrivial: rand / rand_distr are unconditional dependencies and RNG usage threads through several modules, so gating them cleanly needs an audit. Before scoping that, a question for your Typst-plugin case @TimeTravelPenguin: would it be enough to gate the sampling APIs (probability distributions, RNG wrappers) behind a default-on feature you can turn off, keeping the rest of the statistics module? If so, the work narrows considerably.

[TimeTravelPenguin]

@Axect possibly, yes.

I was mostly interested in developing some tools that would allow for much more efficient graphing tools, which primarily required ODE solvers and/or integrators. I cannot recall the exact requirements right now, but the main focus was that we were interested in using something optimised for the job, rather than rolling something mediocre.

More generally, I was interested in writing a mathematics library plugin, allowing folks to hand off heavier computation to WASM.

In short, I was most interested in utilising anything deterministic and without random requirements. That would allow me to offer the Typst community with a bare minimum numerical computation package.

Hopefully that makes sense.

[Axect]

Thanks @TimeTravelPenguin, that confirms the minimal scope is enough: what you need is exactly the deterministic core (ODE solvers, numerical integration, splines, linear algebra), none of which should require an RNG.

Plan, targeted at the next minor release:

1. Make rand / rand_distr optional dependencies behind a default-on rand feature. Existing users see no change; default-features = false (plus the features you want) drops the RNG stack entirely.
2. Gate the sampling APIs (statistics::rand, the distribution sampling half of statistics::dist, weighted uniform, and any other RNG call sites an audit turns up) behind that feature. Deterministic statistics (mean, variance, quantiles, ...) stay available.
3. Add a wasm32-unknown-unknown build job to CI so the no-rand configuration cannot silently regress.

One caveat until the audit is done: if some non-statistics module turns out to depend on RNG internally (e.g. stochastic initialization somewhere in optimization), it will move behind the same feature rather than block the whole plan.

I'll link the PR here when it's up. If you get a chance to try the default-features = false build against your Typst plugin once it lands, that feedback would be valuable.

[TimeTravelPenguin]

Sounds perfect @Axect!

Thanks a lot :)

[Axect]

The implementation is up: #104. Once CI passes and it merges into dev, the deterministic core will be available with

peroxide = { version = "...", default-features = false }

and the new CI job builds exactly that configuration for wasm32-unknown-unknown on every push. It will ship in the next release; I would appreciate it if you could try it against your Typst plugin then.

[Axect]

#104 is merged into dev, so you can already try the no-rand configuration ahead of the release:

[dependencies]
peroxide = { git = "https://github.com/Axect/Peroxide", branch = "dev", default-features = false }

This builds for wasm32-unknown-unknown (CI now checks exactly that target on every push). It will land on crates.io as v0.43.0; the version bump is because the change is technically breaking for anyone who already used default-features = false and relied on the sampling APIs. Any feedback from trying it inside a Typst plugin before the release would be very welcome.

[TimeTravelPenguin]

Thanks @Axect! I will give this a look at ASAP, but it may take a day or two. I will certainly let you know how things go.

[Axect]

No rush at all, take whatever time you need. Considering this issue sat for the better part of a year before I got to it, a day or two is nothing; I appreciate you responding so quickly to such a late fix. Whenever you get around to it, I'll be glad to hear how it goes.