Merge 0.5 #599
Merge 0.5 #599
Conversation
|
The CI still fails — apparently most of the Travis workers don't get the same result I do (can't reproduce). Rand still depends on rand_core 0.2.0 despite this feature being in an un-released version. Not a problem for CI (it uses the repo paths), but we should release rand_core 0.3 and increase the dependency version. |
|
@sicking I've been trying to work out why one of the tests is generating anomalous results and failing, but I think it's just a random failure (I double-checked the code). This is the "counts" results with And without (one test skipped, only up to failing test with 153): I've also adjusted your code slightly — see comments in #593. Do you think this is reasonable? |
benches/seq.rs
Outdated
| @@ -127,7 +127,7 @@ fn seq_iter_unhinted_choose_from_100(b: &mut Bencher) { | |||
| #[bench] | |||
| fn seq_iter_window_hinted_choose_from_100(b: &mut Bencher) { | |||
| let mut rng = SmallRng::from_rng(thread_rng()).unwrap(); | |||
| let x : &[usize] = &[1; 100]; | |||
There was a problem hiding this comment.
Probably want to change the name of the benchmark function.
src/seq/mod.rs
Outdated
| assert!(-30 <= err && err <= 30); | ||
| // Octave: binopdf(x, 1000, 1/9) gives the prob of *count == x | ||
| // Note: have seen 153, which is unlikely but not impossible. | ||
| assert!(72 < *count && *count < 154, "count not close to 1000/9: {}", count); |
There was a problem hiding this comment.
This seems fine. The old limits had no scientific analysis behind them. I mainly picked as small of a number as I could get away with.
There was a problem hiding this comment.
I was actually surprised I had to go this high — binopdf(153, 1000, 1/9) is 1.1e-5. But not impossible and I'm fairly sure the algorithm is right.
| consumed = 1; | ||
| let hint = self.size_hint(); | ||
| lower = hint.0; | ||
| upper = hint.1; |
There was a problem hiding this comment.
I don't have a strong opinion on this one. I answered over in #593. In theory this change will slow down unhinted iterators, but speed up iterators with "unusual" hinting (such as the "window hinted" one in the tests). But in both cases the change should be quite small. And of course less code is always a win.
There was a problem hiding this comment.
It's difficult tying much to theory when it comes to optimisations isn't it? Perhaps simpler code works better with the branch predictor. It's actually the unhinted one that's faster.
There was a problem hiding this comment.
Cool. I agree that using too much theory for optimizations can be dangerous. But this is likewise true for using microbenchmarks.
Either way, the intended win from this code is really small, so I'm totally ok with it being removed.
| @@ -191,17 +191,7 @@ pub trait IteratorRandom: Iterator + Sized { | |||
| let mut result = None; | |||
|
|
|||
| if upper == Some(lower) { | |||
| // Remove this once we can specialize on ExactSizeIterator | |||
| return if lower == 0 { None } else { self.nth(rng.gen_range(0, lower)) }; | |||
There was a problem hiding this comment.
Yeah, removing the comment is probably a good idea. See for example this for a good reason we probably will want to keep this code around no matter what: rust-lang/rust#34433
No description provided.