rustrandom/rand 701
A Rust library for random number generation.
adevore/rudy 62
Judy array implementation in pure Rust
vks/average 21
Calculate the average of a sequence and its error iteratively
Don't use this any more. Use std::sort_unstable
Time series feature extraction for Supervised Learning Modeling
smashtransport/smashanalysis 2
Analysis tools that are useful to calculate observables from SMASH.
Discrete log implementation that can serve as a benchmark for bigints
My portofolio
pull request commentrustrandom/rand
Add geometric and hypergeometric distributions
I was able to find their article on hypergeometric sampling on ResearchGate. I looks like the PDF is available there and complete.
comment created time in a day
pull request commentrustrandom/rand
Add geometric and hypergeometric distributions
Thanks, this looks like good additions!
We are using a rejerction algorithm by Kachitvichyanukul and Schmeiser from 1988 for sampling the binomial distribution, so we can hopefully find their hypergeometric variant as well.
comment created time in a day
push eventvks/book
commit sha 02e535462e00589a535692a7452329bc086a483a
Add link to PR
push time in 6 days
issue commentrustrandom/rand
I think we still need to release rand_core
0.6, which migrates to getrandom
0.2. Is there anything else left to do for this release?
comment created time in 7 days
push eventvks/book
commit sha a2bb6cb616e7beeb77c22a74f20b9b54258c34bc
Mention changes to `IteratorRandom`
push time in 7 days
pull request commentrustrandom/rand
fix accuracy of IteratorRandom::choose()
The value stability tests seem to be failing. Could you please fix this?
Can you squashmerge?
Why squash? The commits seem to be independent enough.
comment created time in 11 days
push eventrustrandom/rand
commit sha 5eb27f0ed95c08d78a442a540949452306e4ba80
Switch to packed_simd_2
commit sha fe34550f4ef28056c73a785f54f908f8fc13070b
Remove `__m64` support This is necessary, because support for `__m64` was removed from nighly Rust [1]. Fixes #1050. [1] https://github.com/rustlang/stdarch/issues/823
commit sha c42d027debd1dbf65e0e8e455851bca4f05faa45
Relax requirement for widening multiply implementation The specialized instructions are already available with `sse2`.
push time in 11 days
issue closedrustrandom/rand
All MMX intrinsics were removed from Rust: https://github.com/rustlang/stdarch/issues/823
This currently causes packed_simd
to not compile (see for instance #1047). Here is the PR that fixes packed_simd
: https://github.com/rustlang/packed_simd/pull/292
Once the new version of packed_simd
is released, we will have to remove support for __m64
to make the tests pass.
closed time in 11 days
vkspull request commentrustrandom/rand
Assuming @dhardy is satisfied, I'm going ahead and merge this.
comment created time in 11 days
push eventrustrandom/rngs
commit sha f6373976999364fbfc5e3c8d33e6c6aa73001a76
Prefer upper bits This is a valuebreaking change to `next_u32` affecting `Xoshiro256{PlusPlus,StarStar}` and `Xoshiro512{Plus,PlusPlus,StarStar}`.
commit sha cbb7d7a489cd0558f5ba9565775d0f009cddcc93
Update changelog and bump version
commit sha 5a7f5095d5596393008b0fa34346bc5d10e20edc
Bump version in root Cargo.toml as well
push time in 15 days
PR merged rustrandom/rngs
This is a valuebreaking change to next_u32
affecting Xoshiro256{PlusPlus,StarStar}
and Xoshiro512{Plus,PlusPlus,StarStar}
.
pr closed time in 15 days
push eventvks/rngs
commit sha 453fae3294b37ef310f01fa2f7998b189015a641
Bump version in root Cargo.toml as well
push time in 15 days
pull request commentrustrandom/rand
Thanks for taking care of this! I did not yet look at the code, but the documentation looks good. Maybe we should mention now in the docs of choose
that choose_stable
exists?
comment created time in 15 days
Pull request review commentrustrandom/rand
mod simd_wmul { } wmul_impl! { (u16x2, u32x2),, 16 } #[cfg(not(target_feature = "sse2"))] wmul_impl! { (u16x4, u32x4),, 16 } #[cfg(not(target_feature = "sse4.2"))]+ #[cfg(not(target_feature = "sse2"))] wmul_impl! { (u16x8, u32x8),, 16 }
I think it is to provide a specialized implementation that uses less instructions.
comment created time in 15 days
push eventrustrandom/rand
commit sha 4bc9952031225721d23e10cc7f6dc39d1f1ba098
rand_distr: add from_mean_cv ctor to Normal and LogNormal Also improve doc for other ctors
commit sha 33fe3c2582c35aeffc2c221d07fc767220169cbb
Add from_zscore and address review
commit sha e72d25a490069505ae5442308843b579830dd883
Don't duplicate `assert_almost_eq` macro
commit sha 9a9903eebbc066559e6c6f50eb78dd5f7639ff06
Use more efficent code and slightly relax precision of test
commit sha 4ba6403651b1105ee2c5543e0ecbe1b0cbe762c8
Update correlated normal samples example Coauthoredby: Vinzent Steinberg <Vinzent.Steinberg@gmail.com>
commit sha ce642d4cf89d613c01c01dbffa7125d9f55b733b
Update correlated lognormal samples example Coauthoredby: Vinzent Steinberg <Vinzent.Steinberg@gmail.com>
commit sha 77c4732f16fc2c19d376a626e7ece5321c789061
Adjust error message/doc
push time in 16 days
PR merged rustrandom/rand
Closes #1042. Ref. #775 (partially implemented here).
pr closed time in 16 days
pull request commentrustrandom/rand
rand_distr: add from_mean_cv ctor to Normal and LogNormal
Thanks, looks good!
comment created time in 16 days
push eventrustrandom/rand
commit sha 14ba1bbb4dbe343698739fc288232a6ed125f69f
Fix some clippy warnings Also reenable some lints that no longer cause warnings.
push time in 17 days
PR merged rustrandom/rand
Also reenable some lints that no longer cause warnings.
pr closed time in 17 days
push eventrustrandom/rand
commit sha 8d385c63fe6513ad389e95c4ccf93c2ad801d4e7
Document value stability of `IteratorRandom::choose` Fixes #1051.
commit sha 671e0a29b0766ed629976b889c0fc7094e6fb1f0
Improve wording as suggested by @dhardy
push time in 17 days
issue closedrustrandom/rand
Stable version of rand::seq::IteratorRandom::choose
Background
What is your motivation?
Provide a way to produce predictable results for (a function similar to) rand::seq::IteratorRandom::choose
no matter what type of iterator it is.
Right now the behaviour of rand::seq::IteratorRandom::choose
depends on the type of Iterator that is passed in. This is mentioned in the docs as an "optimization" however it isn't clear that this is a behaviour affecting "optimization". Furthermore there is no good alternative function which doesn't have this "optimization".
Example: https://play.rustlang.org/?version=stable&mode=debug&edition=2018&gist=a62f77f38f4a0b66df57106d0cf6a4a4
extern crate rand; // 0.7.3
extern crate rand_pcg; // 0.2.1
fn choose(i: &mut dyn Iterator<Item=u32>) > u32 {
let mut rng = rand_pcg::Pcg32::new(0xcafef00dd15ea5e5, 0xa02bdbf7bb3c0a7);
rand::seq::IteratorRandom::choose(i, &mut rng).unwrap()
}
fn main() {
dbg!(choose(&mut (0..32))); // 5
dbg!(choose(&mut (0..32).filter(_ true))); // 3
}
What type of application is this? numerical simulation
Feature request
 Clarify the documentation to emphasize that
rand::seq::IteratorRandom::choose
has different behaviour depending on the return value of thesize_hint
method.  Provide an alternative function that will select the same element (including
Rng
state) for any iterator of the same length.
Workarounds
Unify type:
One option to get a consistent result is ensure that you are always working with the same type. For example the following always collects to a Vec
.
fn stable_choose_collect<T>(i: impl Iterator<Item=T>, mut rng: impl rand::Rng) > Option<T> {
rand::seq::IteratorRandom::choose(i.collect::<Vec<_>>().into_iter(), &mut rng)
}
Get rid of size_hint.
It would be more "proper" to make a wrapper type but since rand::seq::IteratorRandom::choose
only performs its "optimization" if lower == upper
we just need to make those not equal. The easiest way to do this is is call .filter(_ true)
on the iterator. Because it can't tell how many elements you will filter it will set the lower bound to 0
.
fn stable_choose_no_hint<T>(i: impl Iterator<Item=T>, mut rng: impl rand::Rng) > Option<T> {
rand::seq::IteratorRandom::choose(i.filter(_ true), &mut rng)
}
closed time in 17 days
kevincoxPull request review commentrustrandom/rand
mod simd_wmul { } wmul_impl! { (u16x2, u32x2),, 16 } #[cfg(not(target_feature = "sse2"))] wmul_impl! { (u16x4, u32x4),, 16 } #[cfg(not(target_feature = "sse4.2"))]+ #[cfg(not(target_feature = "sse2"))] wmul_impl! { (u16x8, u32x8),, 16 }
I think packed_simd provides a fallback implementation?
comment created time in 17 days
push eventvks/rand
commit sha e82d1f2b15564830836fbc4dd17f7175e92548f6
Relax requirement for widening multiply implementation The specialized instructions are already available with `sse2`.
push time in 17 days
push eventvks/packed_simd
commit sha 78a1fe714071009bd5935af922643d14fd9eb634
Fix typo
push time in 17 days
fork vks/packed_simd
Portable Packed SIMD Vectors for Rust standard library
https://rustlang.github.io/packed_simd/packed_simd/
fork in 17 days
issue commentrustrandom/rand
Partiallysampled random numbers
This seems to be related to #1014, which discusses algorithms that sample bits only as needed.
comment created time in 17 days
issue commentrustrandom/rand
Stable version of rand::seq::IteratorRandom::choose
I still can't think of an application, but I guess we could add IteratorRandom::choose_stable
. @dhardy What do you think?
comment created time in 17 days
push eventvks/rand
commit sha d92c74c26186e18af6ec74b0f879d292f42c628f
Improve wording as suggested by @dhardy
push time in 17 days
Pull request review commentrustrandom/rand
rand_distr: add from_mean_cv ctor to Normal and LogNormal
where F: Float, StandardNormal: Distribution<F> /// Error type returned from `Normal::new` and `LogNormal::new`. #[derive(Clone, Copy, Debug, PartialEq, Eq)] pub enum Error { /// `std_dev < 0` or `nan`. StdDevTooSmall,+ /// The mean value is too small (lognormal samples must be positive)+ MeanTooSmall,+ /// The standard deviation or other dispersion parameter is negative,+ /// infinite, or notanumber.+ BadVariance, } impl fmt::Display for Error { fn fmt(&self, f: &mut fmt::Formatter<'_>) > fmt::Result { f.write_str(match self { Error::StdDevTooSmall => "std_dev < 0 or is NaN in normal distribution",+ Error::MeanTooSmall => "mean < 0 or NaN in lognormal distribution",+ Error::BadVariance => "variation parameter is negative or nonfinite in (log)normal distribution",
I think this is the only remaining concern, otherwise this seems ready to merge.
comment created time in 17 days
issue commentcydal/tsExtract
The statistic function currently in win_stats are basic and more could be added.
I think numpy.linalg.norm
calculates the sum of squares. The name is very different though.
comment created time in 20 days
issue commentrustrandom/rand
Is there a `L'Ecuyer` or MRG32k3a implementation?
Now this is also possible with Chacha (depending on how it is actually used  did not check the details of the implementation in this lib).
With Chacha you could just generate random seeds, iterate through all possible seeds, or use the set_stream
method. You can also skip ahead a variable number of words with set_word_pos
.
Another argument is that perhaps one is moving some existing stuff to Rust and want to keep the same numbers. The existing stuff is likely to use a popular RNG, such as some MersenneTwister variant or MRG32k3a.
The design of Rand is extensible, you can use a crate (or implement it yourself) if you want to use a legacy RNG.
Personally I find it surprising that so much care seems to be taken of in the design of this lib, and yet the author does not seem all too familiar with the scientific community needs.
What needs of the scientific community are not addressed?
comment created time in 20 days
issue commentrustrandom/rand
This patch uses the fixed packed_simd
version:
diff git a/Cargo.toml b/Cargo.toml
index 40ea48204e..9284f3084f 100644
 a/Cargo.toml
+++ b/Cargo.toml
@@ 61,8 +61,8 @@ serde = { version = "1.0.103", features = ["derive"], optional = true }
[dependencies.packed_simd]
# NOTE: so far no version works reliably due to dependence on unstable features
version = "0.3"
# git = "https://github.com/rustlangnursery/packed_simd"
+package = "packed_simd_2"
+version = "0.3.4"
optional = true
features = ["into_bits"]
However, we still need to fix the following line:
> src/distributions/utils.rs:190:35

190  wmul_impl_16! { u16x4, __m64, _mm_mulhi_pu16, _mm_mullo_pi16 }
__m64
, _mm_mulhi_pu16
, and _mm_mullo_pi16
no longer exist and were replaced.
comment created time in a month
issue commentrustrandom/rand
SmallRng seed is too big, and seedability
How would a user even be able to create a seeding algorithm on their own?
Most of the time, users can just generate a random seed. We could enforce this by hiding the seeds behind an opaque type that can only be randomly initialized, but this breaks some use cases where access to the full seed is required.
Specifically for SmallRng, if the seed is 256 bits but the state space is 2**256 minus one, then you have a seeding procedure that is by definition dangerous and impossible to make safe.
Why is it dangerous? It is impossible to enumerate all states, and it's almost impossible that two random seeds collide.
crypto requires safety but all other users want convenience.
SeedableRng::from_seed
is already inconvenient: You would have to write SmallRng::from_seed([1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])
to get a "bad" seed. ("Bad" only means that you will get slightly more 0 bits than expected for about 10 samples.) Compare that to SmallRng::seed_from_u64(1)
or SmallRng::from_entropy()
, neither of which suffer from this problem.
So I think this is mostly a doc issue?
I think we should just add a paragraph to SeedableRng::from_seed
that in most cases the seed should either be randomly generated or that seed_from_u64
or rand_seeder
should be preferred.
comment created time in a month
issue commentrustrandom/rand
SmallRng seed is too big, and seedability
I think it's not ideal that generators are advertising a larger state space than they can provide, and then expect the user to somehow prevent bad initializations.
Were is this advertised? The documentation of SeedableRng::from_seed
says:
PRNG implementations are allowed to assume that bits in the seed are well distributed. That means usually that the number of one and zero bits are roughly equal, and values like 0, 1 and (size  1) are unlikely. Note that many noncryptographic PRNGs will show poor quality output if this is not adhered to. If you wish to seed from simple numbers, use seed_from_u64 instead.
I don't think we can completely absolve users from the possibility of choosing bad seeds. Even for a CSPRNG, a predictable seed makes the generated random numbers predictable. This is similar to choosing a weak password instead of a randomly generated one.
Almost all noncrypto PRNGS have some seeds that are problematic.
We could declare SeedableRng::from_seed
as a lowlevel API that should not be used directly and recommend rand_seeder
as the "default" for reproducibility.
comment created time in a month
issue commentrustrandom/rand
Interest in a weighted index based on balanced trees?
I'm not sure how significant the performance gains world be, but in principle such an alternative implementation could live in rand_distr
. The is a precedent: we already have a WeightedIndex
implementation employing the alias method there.
comment created time in a month
startedartichoke/artichoke
started time in a month
issue commentrustrandom/rand
Stable version of rand::seq::IteratorRandom::choose
I think documenting the behavior is the best way forward (see #1052 for my attempt). I don't really see a strong motivation for providing a stable alternative implementation. As far as I can see, the only use case with somewhat surprising behavior are noop iterator combinators, which seems like an extreme edge case.
comment created time in a month
push eventvks/rand
commit sha 62d27ca67cef4d996e082cf0d973db7115125f8a
Document value stability of `IteratorRandom::choose` Fixes #1051.
push time in a month
push eventvks/average
commit sha 28ec37eff84ef83ec497203d3eb4f90c4eca67f2
Fix `cargo publish`
commit sha f3e79adbf62c1aa55dcd797f29026941383fdc16
Bump version
push time in a month
push eventvks/average
commit sha 20d1b385c763659ad6a051d5df09dc7b29682907
Bump version
push time in a month
push eventvks/rustbyexample
commit sha 363499a5769e6820b11e29f2a75d4954fae352ec
Prefer `const` over `static`
push time in a month
push eventvks/average
commit sha 17464b2c95529541d04f9e154b94da2987705153
Improve `Merge` documentation
push time in a month
issue closedAxect/Peroxide
DataFrame documentation is missing on docs.rs
The link to it on docs.rs is dead: https://docs.rs/peroxide/0.26.4/peroxide/structure/dataframe/index.html
closed time in a month
vksissue commentAxect/Peroxide
DataFrame documentation is missing on docs.rs
My bad, I should have checked that you are not linking to docs.rs. Thanks for the quick reply!
comment created time in a month
issue commentBurntSushi/ruststats
Link to Welford paper on streaming algorithms no longer available
There is also a paper generalizing the algorithm for calculating (weighted) moments of any order: https://doi.org/10.1007/s001800150637z
comment created time in a month
issue openedrustrandom/rand
All MMX intrinsics were removed from Rust: https://github.com/rustlang/stdarch/issues/823
This currently causes packed_simd
to not compile (see for instance #1047). Here is the PR that fixes packed_simd
: https://github.com/rustlang/packed_simd/pull/292
Once the new version of packed_simd
is released, we will have to remove support for __m64
to make the tests pass.
created time in a month
startedhacspec/hacspec
started time in a month
pull request commentrustrandom/rand
rand_distr: add from_mean_cv ctor to Normal and LogNormal
* `from_zscore` allows generating two covariant samples `x1, x2` (correlation coefficient = 1 or 1 (via σ), using Pearson correlation coefficient
Couldn't you generate an arbitrary number of covariant samples?
So how far do we go?
from_zscore
on its own isn't very useful; being able to generate partiallycorrelated samples is more useful, but essentially just a 2dimensional normal distribution (with different parametrisation). Probably though 2dimensional correlated samples is as far as we should go outside of a linearalgebra package.
I think multivariate normal distributions is something we might want to consider later. If we require linear algebra, we could make it an optional feature.
comment created time in a month
pull request commentdhardy/rand
Use more efficent code and slightly relax precision of test
No problem! Thanks for the the review.
comment created time in a month
push eventvks/average
commit sha 94ecc95c4c7056e597a34cdecd450991057e7e89
Only include necessary files in crate
push time in a month
push eventvks/book
commit sha 445e96aeaa7f060e86777e9bf38a8341d93925d5
Mention split of `nightly` and `simd_support` feature
push time in a month
PR opened dhardy/rand
See https://github.com/rustrandom/rand/pull/1044#discussion_r488093947 and following.
pr created time in a month
push eventvks/average
commit sha 1657857f0b593695a74655d91a2ce1d9560cbc36
Update dependencies
commit sha 4d98d5ac4a3bebdf58092068b8f3b018fe62aa0e
Forbid unsafe code
commit sha 0fbd2551a44d3edff512f86d638d65a241fa7f2d
Bump version
push time in a month
Pull request review commentrustrandom/rand
rand_distr: add from_mean_cv ctor to Normal and LogNormal
where F: Float, StandardNormal: Distribution<F> /// Error type returned from `Normal::new` and `LogNormal::new`. #[derive(Clone, Copy, Debug, PartialEq, Eq)] pub enum Error { /// `std_dev < 0` or `nan`. StdDevTooSmall,+ /// The mean value is too small (lognormal samples must be positive)+ MeanTooSmall,+ /// The standard deviation or other dispersion parameter is negative,+ /// infinite, or notanumber.+ BadVariance, } impl fmt::Display for Error { fn fmt(&self, f: &mut fmt::Formatter<'_>) > fmt::Result { f.write_str(match self { Error::StdDevTooSmall => "std_dev < 0 or is NaN in normal distribution",+ Error::MeanTooSmall => "mean < 0 or NaN in lognormal distribution",+ Error::BadVariance => "variation parameter is negative or nonfinite in (log)normal distribution",
Don't we allow negative standard deviations now?
comment created time in a month
Pull request review commentrustrandom/rand
rand_distr: add from_mean_cv ctor to Normal and LogNormal
where F: Float, StandardNormal: Distribution<F> impl<F> LogNormal<F> where F: Float, StandardNormal: Distribution<F> { /// Construct a new `LogNormal` distribution with the given mean /// and standard deviation of the logarithm of the distribution.+ /// Construct, from (logspace) mean and standard deviation+ ///+ /// Parameters are the "standard" logspace measures (these are the mean+ /// and standard deviation of the logarithm of samples):+ ///+ ///  `mu` (`μ`, unrestricted) is the mean of the underlying distribution+ ///  `sigma` (`σ`, must be finite) is the standard deviation of the+ /// underlying Normal distribution+ #[inline]+ pub fn new(mu: F, sigma: F) > Result<LogNormal<F>, Error> {+ let norm = Normal::new(mu, sigma)?;+ Ok(LogNormal { norm })+ }++ /// Construct, from (linearspace) mean and coefficient of variation+ ///+ /// Parameters are linearspace measures:+ ///+ ///  mean (`μ > 0`) is the (real) mean of the distribution+ ///  coefficient of variation (`cv = σ / μ`, requiring `cv ≥ 0`) is a+ /// standardized measure of dispersion+ ///+ /// As a special exception, `μ = 0, cv = 0` is allowed (samples are `inf`). #[inline] pub fn new(mean: F, std_dev: F) > Result<LogNormal<F>, Error> { if !(std_dev >= F::zero()) { return Err(Error::StdDevTooSmall);+ pub fn from_mean_cv(mean: F, cv: F) > Result<LogNormal<F>, Error> {+ if cv == F::zero() {+ let mu = mean.ln();+ let norm = Normal::new(mu, F::zero()).unwrap();+ return Ok(LogNormal { norm }); } Ok(LogNormal { norm: Normal::new(mean, std_dev).unwrap(), })+ if !(mean > F::zero()) {+ return Err(Error::MeanTooSmall);+ }+ if !(cv >= F::zero()) {+ return Err(Error::BadVariance);+ }++ // Using X ~ lognormal(μ, σ), CV² = Var(X) / E(X)²+ // E(X) = exp(μ + σ² / 2) = exp(μ) × exp(σ² / 2)+ // Var(X) = exp(2μ + σ²)(exp(σ²)  1) = E(X)² × (exp(σ²)  1)+ // but Var(X) = (CV × E(X))² so CV² = exp(σ²)  1+ // thus σ² = log(CV² + 1)+ // and exp(μ) = E(X) / exp(σ² / 2) = E(X) / sqrt(CV² + 1)+ let a = F::one() + cv * cv; // e+ // let mu = F::from(0.5).unwrap() * (mean * mean / a).ln();+ let mu = (mean / a.sqrt()).ln();+ let sigma = a.ln().sqrt();+ let norm = Normal::new(mu, sigma)?;+ Ok(LogNormal { norm })+ }++ /// Sample from a zscore+ ///+ /// This may be useful for generating correlated samples, as follows.+ /// ```+ /// # use rand::prelude::*;+ /// # use rand_distr::{LogNormal, StandardNormal};+ /// let mut rng = thread_rng();+ /// let z = StandardNormal.sample(&mut rng);+ /// let x1 = LogNormal::from_mean_cv(3.0, 1.0).unwrap().from_zscore(z);+ /// let x2 = LogNormal::from_mean_cv(2.0, 1.0).unwrap().from_zscore(z);+ /// ```
/// This may be useful for generating correlated samples `x1` and `x2`
/// from two different distributions, as follows.
/// ```
/// # use rand::prelude::*;
/// # use rand_distr::{LogNormal, StandardNormal};
/// let mut rng = thread_rng();
/// let z = StandardNormal.sample(&mut rng);
/// let x1 = LogNormal::from_mean_cv(3.0, 1.0).unwrap().from_zscore(z);
/// let x2 = LogNormal::from_mean_cv(2.0, 4.0).unwrap().from_zscore(z);
/// ```
comment created time in a month
Pull request review commentrustrandom/rand
rand_distr: add from_mean_cv ctor to Normal and LogNormal
impl std::error::Error for Error {} impl<F> Normal<F> where F: Float, StandardNormal: Distribution<F> { /// Construct a new `Normal` distribution with the given mean and /// standard deviation.+ /// Construct, from mean and standard deviation+ ///+ /// Parameters:+ ///+ ///  mean (`μ`, unrestricted)+ ///  standard deviation (`σ`, must be finite) #[inline] pub fn new(mean: F, std_dev: F) > Result<Normal<F>, Error> { if !(std_dev >= F::zero()) { return Err(Error::StdDevTooSmall);+ if !std_dev.is_finite() {+ return Err(Error::BadVariance); } Ok(Normal { mean, std_dev }) }++ /// Construct, from mean and coefficient of variation+ ///+ /// Parameters:+ ///+ ///  mean (`μ`, unrestricted)+ ///  coefficient of variation (`cv = abs(σ / μ)`)+ #[inline]+ pub fn from_mean_cv(mean: F, cv: F) > Result<Normal<F>, Error> {+ if !cv.is_finite()  cv < F::zero() {+ return Err(Error::BadVariance);+ }+ let std_dev = cv * mean;+ Ok(Normal { mean, std_dev })+ }++ /// Sample from a zscore+ ///+ /// This may be useful for generating correlated samples, as follows.+ /// ```+ /// # use rand::prelude::*;+ /// # use rand_distr::{Normal, StandardNormal};+ /// let mut rng = thread_rng();+ /// let z = StandardNormal.sample(&mut rng);+ /// let x1 = Normal::new(0.0, 1.0).unwrap().from_zscore(z);+ /// let x2 = Normal::new(2.0, 1.0).unwrap().from_zscore(z);+ /// ```
/// This may be useful for generating correlated samples `x1` and `x2`
/// from two different distributions, as follows.
/// ```
/// # use rand::prelude::*;
/// # use rand_distr::{Normal, StandardNormal};
/// let mut rng = thread_rng();
/// let z = StandardNormal.sample(&mut rng);
/// let x1 = Normal::new(0.0, 1.0).unwrap().from_zscore(z);
/// let x2 = Normal::new(2.0, 3.0).unwrap().from_zscore(z);
/// ```
comment created time in a month
issue commentrustrandom/rand
Compilation fails with "nightly" feature due to packedsimd dependency
With Rand 0.8, you can consider forwarding the nightly feature again, as it will not longer enable simd_support
with the associated stability issues.
comment created time in a month
issue openedrustrandom/rand
Test "nightly" and "simd_support" features independently
From https://github.com/rustrandom/rand/pull/1048#pullrequestreview493642728:
Yes, ideally we should have at least one test of each independently. We could just use different flags on Travis and AppVeyor.
created time in a month
push eventrustrandom/rand
commit sha b2b53f4b8821b0476109de5bcf79e43951208a45
Disentangle `nightly` and `simd_support` feature Now `nightly` can be used without implying `simd_support`. This hopefully makes the `nightly` feature more stable and improves compilation time if `simd_support` is not required. The documentation and changelog were updated accordingly.
commit sha 32ff4be358b7379a966479398edf0b74ac57d8cb
Improve feature stability comment
commit sha 8e22db5f08358f0708ca3e15c2d36c885d1fd5f7
Mention PR number in changelog
push time in a month
PR merged rustrandom/rand
Now nightly
can be used without implying simd_support
. This
hopefully makes the nightly
feature more stable and improves
compilation time if simd_support
is not required.
The documentation and changelog were updated accordingly.
Fixes #1047.
pr closed time in a month
issue closedrustrandom/rand
Compilation fails with "nightly" feature due to packedsimd dependency
Compiling rand 0.7.3 fails with rustc 1.46.0 (04488afe3 20200824) and later with features "nightly"
, due to the packedsimd 0.3.3 dependency failing to build.
error[E0432]: unresolved import `crate::arch::x86_64::__m64`
> /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/api/into_bits/arch_specific.rs:51:15

51  $($arch_ty),*
 ^^^^^^^^ no `__m64` in `arch::x86_64`
...
86  / impl_arch!(
87   [x86["x86"]: __m64], [x86_64["x86_64"]: __m64],
88   [arm["arm"]: int8x8_t, uint8x8_t, poly8x8_t, int16x4_t, uint16x4_t,
89   poly16x4_t, int32x2_t, uint32x2_t, float32x2_t, int64x1_t,
... 
96   test: test_v64
97   );
 __ in this macro invocation

= note: this error originates in a macro (in Nightly builds, run with Z macrobacktrace for more info)
error[E0432]: unresolved import `crate::arch::x86_64::_mm_movemask_pi8`
> /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask/x86/sse.rs:47:21

47  use crate::arch::x86_64::_mm_movemask_pi8;
 ^^^^^^^^^^^^^^^^^^^^^
  
  help: a similar name exists in the module: `_mm_movemask_epi8`
 no `_mm_movemask_pi8` in `arch::x86_64`

::: /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask.rs:41:1

41  impl_mask_reductions!(m8x8);
  in this macro invocation

= note: this error originates in a macro (in Nightly builds, run with Z macrobacktrace for more info)
error[E0432]: unresolved import `crate::arch::x86_64::_mm_movemask_pi8`
> /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask/x86/sse.rs:62:21

62  use crate::arch::x86_64::_mm_movemask_pi8;
 ^^^^^^^^^^^^^^^^^^^^^
  
  help: a similar name exists in the module: `_mm_movemask_epi8`
 no `_mm_movemask_pi8` in `arch::x86_64`

::: /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask.rs:41:1

41  impl_mask_reductions!(m8x8);
  in this macro invocation

= note: this error originates in a macro (in Nightly builds, run with Z macrobacktrace for more info)
error[E0432]: unresolved import `crate::arch::x86_64::_mm_movemask_pi8`
> /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask/x86/sse.rs:47:21

47  use crate::arch::x86_64::_mm_movemask_pi8;
 ^^^^^^^^^^^^^^^^^^^^^
  
  help: a similar name exists in the module: `_mm_movemask_epi8`
 no `_mm_movemask_pi8` in `arch::x86_64`

::: /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask.rs:47:1

47  impl_mask_reductions!(m16x4);
  in this macro invocation

= note: this error originates in a macro (in Nightly builds, run with Z macrobacktrace for more info)
error[E0432]: unresolved import `crate::arch::x86_64::_mm_movemask_pi8`
> /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask/x86/sse.rs:62:21

62  use crate::arch::x86_64::_mm_movemask_pi8;
 ^^^^^^^^^^^^^^^^^^^^^
  
  help: a similar name exists in the module: `_mm_movemask_epi8`
 no `_mm_movemask_pi8` in `arch::x86_64`

::: /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask.rs:47:1

47  impl_mask_reductions!(m16x4);
  in this macro invocation

= note: this error originates in a macro (in Nightly builds, run with Z macrobacktrace for more info)
error[E0432]: unresolved import `crate::arch::x86_64::_mm_movemask_pi8`
> /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask/x86/sse.rs:47:21

47  use crate::arch::x86_64::_mm_movemask_pi8;
 ^^^^^^^^^^^^^^^^^^^^^
  
  help: a similar name exists in the module: `_mm_movemask_epi8`
 no `_mm_movemask_pi8` in `arch::x86_64`

::: /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask.rs:52:1

52  impl_mask_reductions!(m32x2);
  in this macro invocation

= note: this error originates in a macro (in Nightly builds, run with Z macrobacktrace for more info)
error[E0432]: unresolved import `crate::arch::x86_64::_mm_movemask_pi8`
> /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask/x86/sse.rs:62:21

62  use crate::arch::x86_64::_mm_movemask_pi8;
 ^^^^^^^^^^^^^^^^^^^^^
  
  help: a similar name exists in the module: `_mm_movemask_epi8`
 no `_mm_movemask_pi8` in `arch::x86_64`

::: /home/isis/.cargo/registry/src/github.com1ecc6299db9ec823/packed_simd0.3.3/src/codegen/reductions/mask.rs:52:1

52  impl_mask_reductions!(m32x2);
  in this macro invocation

= note: this error originates in a macro (in Nightly builds, run with Z macrobacktrace for more info)
It appears that packedsimd has been failing to build on nightlies for a while now. I've worked around this by not forwarding the "nightly" feature in https://github.com/dalekcryptography/ed25519dalek to our rand dependency.
closed time in a month
isislovecruftpush eventvks/rand
commit sha faad0b5ac334f2a14ba4d7e52272487c357bce6c
Mention PR number in changelog
push time in a month
push eventvks/rand
commit sha e758f9540c91ae1c3cf5d2033389f9f69cc2160c
Improve feature stability comment
push time in a month
pull request commentrustrandom/rand
Disentangle `nightly` and `simd_support` feature
It seems like __m64
was removed from nightly, so maybe we should stop supporting it as well. But maybe that can wait until packed_simd
is fixed.
comment created time in a month
pull request commentrustrandom/rand
Disentangle `nightly` and `simd_support` feature
This will also require an update to the Rand book.
The CI does not check whether nightly
and simd_support
work independently. Should we add this? This would require running the tests two more times, or alternatively running cargo check
two times.
comment created time in a month
PR opened rustrandom/rand
Now nightly
can be used without implying simd_support
. This
hopefully makes the nightly
feature more stable and improves
compilation time if simd_support
is not required.
The documentation and changelog were updated accordingly.
Fixes #1047.
pr created time in a month
issue commentrustrandom/rand
Compilation fails with "nightly" feature due to packedsimd dependency
@dhardy This is not quite true, we also depend on the nightly
feature for implementing TrustedLen
and using slice_partition_at_index
. These do not have their own features. Furthermore, sometimes nightly
is required instead or in addition to simd_support
, but this should be fixed.
I don't think we can do much to avoid breakage like this, it's to be expected when using nightly which lacks the stability guarantees of stable Rust. An option would be to have a feature for each nightly functionality, so breakage can be isolated, but is this worth the complexity?
comment created time in a month
push eventrustrandom/rand
commit sha d580894e2170e93debc57b686d9d4ddf88147f91
update StdRng docs after switch to ChaCha12 (#1028)
push time in a month
issue openedrustrandom/rand
Consider renaming `RngCore`to `BitRng`
Looking at the redesign of numpy.random
, I realized that their API became more similar to ours. Their Generator
class is almost equivalent to our Rng
trait, and their BitGenerator
class is very similar to RngCore + SeedableRng
. I like their names more than ours, because BitGenerator
seems more descriptive than RngCore
. Maybe it is worth the churn to rename it to BitRng
for Rand 1.0?
(Other observations are that their API allows for drawing an arbitrary number number of samples, which is more vectorization friendly than our API. It also seems like they deprecated their global RNG! They also added a SeedSequence
class (based on this), which is similar to rand_seeder
.)
created time in a month