Rand works fine without std. Floating point math however needs std, unless libm is used.

rand and nalgebra offer multiple features for this:

• std
• alloc
• libm (only nalgebra)

AFAICT, std/alloc features are the norm across the ecosystem and it probably makes sense to adopt this too.

One disadvantage is that #[cfg] will appear more often and can increase mental load for contributors. Local testing will also become more difficult, but that's probably a price worth paying for good no_std support. Good documentation (for contributors and users) would also help.

Just some notes, I've played around with it and might go for a PR:

• std effectively includes alloc and libm
• feature std can depend on alloc but not libm (dependency mess)
• every feature activates same feature in dependency "std" = ["nalgebra?/std", ...], default should include std
• libm only really makes sense when in no_std (compile_error! via cfg prob. too much?)
• Categorical, Empirical need alloc
• Multivariates (Dirichlet, MVN, MVS, Multinomial)
  • require libm or std (float operations in nalgebra, e.g. Complex<f32>)
  • alloc or std add heap allocation (DVector, DMatrix, nalgebra::Dyn) support
• some code can be rewritten to avoid allocations (avoid feature-gating stuff that doesn't 100% need it)
• i don't think there's anything in the entire library that needs std. no_std + alloc + libm is probably good enough for everything? At least so far