Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move XorShiftRng to its own crate #557

Merged
merged 15 commits into from Jul 24, 2018
Merged

Conversation

vks
Copy link
Collaborator

@vks vks commented Jul 16, 2018

Also recommend StdRng rather than the deprecated IsaacRng.

The main motivation for this is that we can remove the generator from Rand and that it is still possible to reproduce the results.

Also recommend `StdRng` rather than the deprecated `IsaacRng`.
Copy link
Member

@dhardy dhardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, though CI has a few complaints.

src/prng/mod.rs Outdated

pub use self::chacha::ChaChaRng;
pub use self::hc128::Hc128Rng;
pub use self::xorshift::XorShiftRng;
pub use ::rand_xorshift::XorShiftRng;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally this should use deprecated::XorShiftRng. And then SmallRng will need to change the import path to avoid deprecation warnings.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also the deprecation warning itself should suggest the new path

@vks
Copy link
Collaborator Author

vks commented Jul 16, 2018 via email

@dhardy
Copy link
Member

dhardy commented Jul 16, 2018

I didn't pay much attention to keywords... but is there a problem with having too many?

@vks
Copy link
Collaborator Author

vks commented Jul 18, 2018

is there a problem with having too many?

There is an upper limit of 5, but we are using less than that. Anyway, I made the rand_xorshift keywords consistent with what we have elsewhere.

@vks
Copy link
Collaborator Author

vks commented Jul 18, 2018

WASM fails as expected, but I can't see other failures.

@dhardy
Copy link
Member

dhardy commented Jul 18, 2018

There are some broken documentation links; check the bottom: https://travis-ci.org/rust-lang-nursery/rand/jobs/405253376

This is a different issue (can you investigate?): https://travis-ci.org/rust-lang-nursery/rand/jobs/405253378

Also there was a warning about unused #[macro_use].

Be nice if you can investigate; I have very little time this week.

@vks
Copy link
Collaborator Author

vks commented Jul 18, 2018

  • I fixed the broken links.
  • The macro warning can be fixed, but we probably will have to increase the required serde version. (There is no warning with an old version, and I suspect compilation will fail for those versions if I fix the warning.)
  • Not sure about the WASM failures.

@vks
Copy link
Collaborator Author

vks commented Jul 18, 2018

The WASM failure happens on master as well, so I think it is orthogonal to this PR.

@dhardy
Copy link
Member

dhardy commented Jul 18, 2018

Yes, sorry, the WASM failure is a known issue at the moment: koute/cargo-web#116

I guess then we should just ignore the warning for now.

@dhardy dhardy added the D-review Do: needs review label Jul 18, 2018
Copy link
Contributor

@pitdicker pitdicker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍. Left two small comments.

What should the version number of these crates be? It is pretty much stable, but the depends on rand_core < 1.0.

appveyor = { repository = "alexcrichton/rand" }

[features]
serde1 = ["serde", "serde_derive"] # enables serde for BlockRng wrapper
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this only needs serde_derive? And the comment is old.

Copy link
Collaborator Author

@vks vks Jul 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so. Actually, it seems like newer versions of serde don't need serde_derive anymore. I'll remove the comments though.


mod xorshift;

pub use self::xorshift::XorShiftRng;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason xorshift.rs can't be moved in with lib.rs?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be. I'm just mirroring what was done before. Why would you prefer this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't matter much, but I've seen more tiny crates like this have everything in just a single file.

Cargo.toml Outdated

[dependencies]
rand_core = { path = "rand_core", version = "0.2", default-features = false }
# only for deprecations and benches:
rand_isaac = { path = "rand_isaac", version = "0.1", default-features = false }
rand_xorshift = { path = "rand_xorshift", version = "0.1", default-features = false }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't have default features (neither does rand_isaac).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove it.

@vks
Copy link
Collaborator Author

vks commented Jul 20, 2018

I realized the serde tests were broken in rand_isaac and rand_xorshift and fixed them.

@@ -18,9 +18,15 @@ travis-ci = { repository = "rust-lang-nursery/rand" }
appveyor = { repository = "alexcrichton/rand" }

[features]
serde1 = ["serde", "serde_derive"] # enables serde for BlockRng wrapper
serde1 = ["serde", "serde_derive", "rand_core/serde1"]
std = []
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't follow why you added an extra std feature... Or does testing serialization need std?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, exactly. The test uses BufWriter, BufReader and bincode, all requiring std.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about only enabling std when testing, or even only when testing in combination with serde? Than we don't need the otherwise useless feature flag.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems a bit fragile. What if you want to test Serde without std? Anyway, this is not possible AFAIK.

src/lib.rs Outdated
@@ -237,7 +237,7 @@
#[cfg(feature="std")] extern crate std as core;
#[cfg(all(feature = "alloc", not(feature="std")))] extern crate alloc;

#[cfg(test)] #[cfg(feature="serde1")] extern crate bincode;
#[cfg(all(feature="serde1", test))] extern crate bincode;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment does not really belong to this PR, but does rand still need bincode as dependency, or do all tests now live in external crates?

Copy link
Collaborator Author

@vks vks Jul 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, after this PR rand does not depend directly on serde or bincode anymore. I removed them.

We might want to implement Serde support for StdRngand SmallRng. The serialization stability guarantees could be the same as for value stability.

@pitdicker
Copy link
Contributor

I realized the serde tests were broken in rand_isaac and rand_xorshift and fixed them.

Does the CI run tests for rand_isaac and rand_xorshift?

@vks
Copy link
Collaborator Author

vks commented Jul 20, 2018

Does the CI run tests for rand_isaac and rand_xorshift?

Yes, but only on nightly due to the cargo test --all --benches command. (Seems like an accident TBH.) However, this does not include the serde tests, because they require features.

I'll push a commit that enable more tests on more targets.

@pitdicker
Copy link
Contributor

pitdicker commented Jul 20, 2018

We might want to implement Serde support for StdRng and SmallRng. The serialization stability guarantees could be the same as for value stability.

Thanks to having a SeedableRng implementation StdRng and SmallRng can give reproducible output, provided the version of rand and the platform remain the same. We don't make stronger guarantees than those, so we are free to chose a more optimal algorithm in future versions or on certain platforms.

I would expect serialization to give stronger reproducibility guarantees than that. That was the reason we didn't implement serialization for those, and it still seems like the right choice to me.

@vks
Copy link
Collaborator Author

vks commented Jul 20, 2018

I would expect serialization to give stronger reproducibility guarantees than that.

Why? I would expect that breaking reproducibility also breaks serialization. And why would you want serialization without reproducibility?

Anyway, I agree the conservative choice is to only implement serialization for named RNGs for now.

I think this PR is ready now?

@pitdicker
Copy link
Contributor

Why? I would expect that breaking reproducibility also breaks serialization. And why would you want serialization without reproducibility?

We are saying the same thing 😄.

Seems a bit fragile. What if you want to test Serde without std? Anyway, this is not possible AFAIK.

Testing serialization without std does not seem worthwile for us (it is a minor feature). Removing the std feature is possible, would you cherry-pick my commit? https://github.com/pitdicker/rand/commits/xorshift-crate

@dhardy
Copy link
Member

dhardy commented Jul 23, 2018

What should the version number of these crates be? It is pretty much stable, but the depends on rand_core < 1.0.

Starting fresh with 0.1 makes sense to me. As you point out, it's not reasonable to use 1.0 until after all dependencies are stable, and IMO this should only happen after the library has existed for some time with no significant changes.

@vks
Copy link
Collaborator Author

vks commented Jul 23, 2018

@pitdicker

Removing the std feature is possible, would you cherry-pick my commit?

Your branch does not work, the serde tests are never executed. Applying the following patche fixes this:

diff --git a/rand_isaac/src/isaac.rs b/rand_isaac/src/isaac.rs
index 6a8121b..a1bd378 100644
--- a/rand_isaac/src/isaac.rs
+++ b/rand_isaac/src/isaac.rs
@@ -453,7 +453,7 @@ mod test {
     }
 
     #[test]
-    #[cfg(all(feature="serde1", feature="std"))]
+    #[cfg(all(feature="serde1"))]
     fn test_isaac_serde() {
         use bincode;
         use std::io::{BufWriter, BufReader};
diff --git a/rand_isaac/src/isaac64.rs b/rand_isaac/src/isaac64.rs
index b77f3bb..30c494a 100644
--- a/rand_isaac/src/isaac64.rs
+++ b/rand_isaac/src/isaac64.rs
@@ -445,7 +445,7 @@ mod test {
     }
 
     #[test]
-    #[cfg(all(feature="serde1", feature="std"))]
+    #[cfg(all(feature="serde1"))]
     fn test_isaac64_serde() {
         use bincode;
         use std::io::{BufWriter, BufReader};
diff --git a/rand_xorshift/src/xorshift.rs b/rand_xorshift/src/xorshift.rs
index 8a93e9a..cf12296 100644
--- a/rand_xorshift/src/xorshift.rs
+++ b/rand_xorshift/src/xorshift.rs
@@ -178,7 +178,7 @@ mod tests {
         }
     }
 
-    #[cfg(all(feature="serde1", feature="std"))]
+    #[cfg(all(feature="serde1"))]
     #[test]
     fn test_xorshift_serde() {
         use bincode;

However, this makes cargo test --features serde1 fail on no_std targets. I guess this is fine, because in this case the serde1 feature would not be tested in any case.

Note that you can push to my branch due to your collaborator privileges.

@pitdicker
Copy link
Contributor

Thank you!

@dhardy You already gave your approval, but there have been changes. Shall I merge?

Copy link
Member

@dhardy dhardy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed again. With some doc tweaks I'm happy to have this merged, though it would be nice to fix the tests first.

@pitdicker does the Travis changes clash with #563?

@@ -4,14 +4,15 @@

extern crate test;
extern crate rand;
extern crate rand_xorshift;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should just use SmallRng in this benchmark?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@@ -18,9 +18,14 @@ travis-ci = { repository = "rust-lang-nursery/rand" }
appveyor = { repository = "alexcrichton/rand" }

[features]
serde1 = ["serde", "serde_derive"] # enables serde for BlockRng wrapper
serde1 = ["serde", "serde_derive", "rand_core/serde1"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feature serde1 implicitly implies std — should probably be documented with a comment here and in the README

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feature serde1 implicitly implies std

What do you mean? We don't require std for the serde1 feature, and Serde works without std. We only need std for the tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry. I mis-understood the double-negative conditional no_std attribute.

@@ -18,14 +18,17 @@
#![deny(missing_debug_implementations)]
#![doc(test(attr(allow(unused_variables), deny(warnings))))]

#![no_std]
#![cfg_attr(not(all(feature="serde1", test)), no_std)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, but is surprising

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only alternative I can see would be making our tests work with no_std.

appveyor = { repository = "alexcrichton/rand" }

[features]
serde1 = ["serde", "serde_derive"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as for rand_isaac

@vks
Copy link
Collaborator Author

vks commented Jul 24, 2018

it would be nice to fix the tests first.

They are failing on master as well, I don't think they are related to this PR.

does the Travis changes clash with #563?

IIRC, #563 includes the changes here, but commented out.

@dhardy
Copy link
Member

dhardy commented Jul 24, 2018

They are failing on master as well, I don't think they are related to this PR.

Hence "nice", not "required". I didn't really want to look all through those AppVeyor logs.

@vks
Copy link
Collaborator Author

vks commented Jul 24, 2018

Hence "nice", not "required". I didn't really want to look all through those AppVeyor logs.

AFAIK, #565 fixes it but is blocked on packed_simd upstream changes.

@dhardy dhardy merged commit f8fd39d into rust-random:master Jul 24, 2018
@vks vks deleted the xorshift-crate branch July 24, 2018 14:13
This was referenced Jul 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D-review Do: needs review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants