-
Notifications
You must be signed in to change notification settings - Fork 431
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
Tracker: planned changes for 0.5 #232
Comments
If we remove |
But the |
Most of the above is implemented now. There are still some changes to About the release process: I think the best method might be to publish a For Also during the release process we need to work out what kind of compatibility release to make for 0.4. |
I just added two extra desired features: Now would be a good time to add any extra requests for this release (but be warned that larger features may get delayed to 0.6 if not ready to merge soon). |
Yes, copying the For switching Hopefully will finish things tomorrow. |
I think we are making pretty good progress towards 0.5 😄. From #286 (comment)
I would still like to see it become available. I think it is settled that it should change from pure conversion functions to distributions, that can use arbitrary precision (not a fixed 32 or 64 bits). So I will basically have to rewrite things. We have to come up with names, and figure out how to expose a second kind of uniform floating point ranges. That is why I left it out of #274. Shall we leave it until after rand 0.5? Do you still want to do the One thing I really want to see is It should not be all that much work to polish the PCG and XoroshiroMT implementations in my |
Perhaps; I don't think we should block 0.5 waiting on it at least.
I asked, and the answer seems to be yes. This is easy to implement but I thought better to wait until most other stuff is done though; I may get to this soon now. (There's additional motivation: we can make the I'm not sure about changing No, I missed the notification on your history article; I'll have a read. |
The choice was between PCG and my Xoroshiro variant. But to be honest I found a problem with the last one, trying to prove it was correct (a while ago actually). A widening multiply does not guarantee uniformity or equidistribution. It should be a 'real', 128 bit multiply. This can be done by using a widening multiply plus a normal multiply, causing a little slowdown (but still faster than PCG). Just to err on the safe side I would make PCG the default, and also because it is better known. |
That sounds good enough to me; I'd rather err on the side of strong than fast-and-weak personally. But you should probably make a post in dhardy#60 to clarify to the people who commented there what the plan is. Also I think perhaps we should remove |
I think removing In my opinion, the following kinds of generators should be considered:
The tradeoffs between 1., 2. and 3. should be clearly documented. (Personally, I think 2. and 5. are extremely niche. 4. could be hidden behind some abstraction or replaced with 1. I don't see a convincing reason to use xoroshiro128* over xoroshiro128+.) |
@vks please see dhardy#58. The intention is to provide both names (e.g. "Practically almost everyone" doesn't fly as an argument; there are still many people using MT19937, and while it might be sufficient for their purposes I won't recommend it just because it's popular. |
Thanks for the link!
In my opinion the argument has some merit, because given the widespread use of generators with linear dependencies, I would expect to hear of practical problems if there were any. Following the same line of thought, I think the statistical quality of MT is ok, the performance seems like a bigger issue in practice. |
@vks I opened #289 regarding your point about dropping
|
I'm kind of leaning toward not having any |
Interesting idea. I wouldn't miss |
Oh, having convenience methods like bools, |
So, to get this back on track, what do we need to do for the 0.5 release?
Is there anything else? It would be really nice to be able to publish |
I think we should not. We have made a good simplification. Also the distinction is not really meaningful, because the change to generate exactly One other thing that I feel is important, is #293. Now that we break user code with the changes to the Personally I am in less of a hurry and would like to see some more changes. But yes, we have something nice now. Time to finish things and get a release. |
What did you think about renaming |
I'm not so fussed about removing Getting the next release out — well it could wait, but
Possibly a good compromise would be to make pre-releases but not make a final release yet; that way we get more testers but only those willing to put up with some more potential breaking changes. |
Shall I try to figure out the changelog? And what do you think about releasing If we want some place to host announcements/posts what do you think of https://pages.github.com/? |
We already have GH pages for this repo: http://rust-lang-nursery.github.io/rand/rand/index.html Yes, I guess we're about ready. #319 affects both rand-core and rand so needs to be merged first. #320 is purely an addition to rand and #297 purely an optimisation so both could be merged after the first pre-release, but can also be merged sooner (#320 just needs review, #297 I don't know?). As I said before, pre-releases first then final release after early-adopters have had a chance to try this out. |
|
I didn't see much point removing it yet either. Though for 0.6 we should definitely consider some cleanup. |
I regret previously releasing |
No reverse dependencies. As far as I know it was only used by @dhardy's experimental branch, and one or two unpublished test crates from me. |
I would probably just use |
@dhardy I think the |
https://crates.io/crates/rand_core/0.1.0-pre.0 The "rand" link is broken; I guess it'll have to be an absolute link to the Crates page. |
I think there's only one issue that still needs addressing before 0.5: #287. As soon as that's done I think I can make a pre-release? |
I was just thinking I have nothing left and would like to see a release 👍. To be honest I don't see much point in pre-releases. Maybe it is good practise, but it only works when people actually use the pre-release. So I would like to see a real release, and if necessary a small point release in a few weeks. |
Currently testing after updating version number: https://travis-ci.org/rust-lang-nursery/rand/builds/358840821 I'll package this as -pre.0 soon; we can still make minor modifications before the 0.5 release (#287; perhaps some Clippy suggestions, maybe doc improvements, ..) |
I think the I had no luck installing clippy for the past few days, but wanted to run it... |
Here's my clippy output. |
I have to admit doing a pre-release was useful! Especially thanks to the announcement on Reddit. It seems to me we are mostly there taking care of the feedback after the pre-release. At least the part I care about 😄. For #359 I have a branch ready. Do we want to try something with #348 now? And maybe hide the |
I have some extra docs in progress. Sorry, I've not been able to devote much time to Rand the last week (and I won't be able to next week either; might get a little time this week though). |
We are just volunteers, right? |
Found something nice in the
So we don't need to change the |
We at least need a version number for the dependency; it complained about that last time. |
rand_core 0.1.0 has been released. |
I'd like to get the following done, then I think we're good for a release:
Not sure about these: We could also look at these, but there's no reason they can't wait IMO: |
I posted new pre-releases 3 days ago: So far there has been little feedback regarding stuff that needs changing, so it looks likely that these will be the final pre-releases. In this case the releases should be made early next week. |
Can you make a PR with the final changes for the release, instead of a direct push (then I can be a second pair of eyes...)? |
Looks to me like all the main things are in place for the 0.2 / 0.5 releases. So do you want to make the PR and I'll release? |
🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉 |
Yes, I know! 🎉 🍰 ⛵ |
To follow up on the release strategy in #205, here is a rough plan for Rand 0.5:
Hc128Rng
Add HC-128 #210SeedableRng::from_rng
to replaceRand
impls on PRNGs; updateseed
type Port new SeedableRng trait #233IndependentSample
→Distribution
and removeSample
Replace distribution::Sample with Distribution + polymorphism over Rng #256Rand
withUniform
distribution Replace distribution::Sample with Distribution + polymorphism over Rng #256Rng
toRng: RngCore
RngCore and extension trait Rng #265Rng
etc. to newrand-core
crate [requiresSampleRng
;MoveAdd rand-core sub-crate and update version numbers #288]Rng
to rand-core crate? #264AddHalfOpen01
distributionRelated issues which need solving:
try_fill_bytes
: Renametry_fill
orfill_bytes
? dhardy/rand#27Uniform
; Distributions: Uniform, Uniform01, Open01, etc. dhardy/rand#81Rand
: Fate of theRand
trait dhardy/rand#83rand-core
members inrand
? dhardy/rand#15Distribution::sample
prototype to use Distribution sample prototype and sized-ness ofRng
#287RngCore
methods?There are some extra changes which should be relatively easy to add after the above:
Range
code Port new Range implementation and only have one uniform float distribution #274CryptoRng: RngCore
extension trait Small changes from experimental branch #273thread_rng()
toHC-128
? Replace ISAAC with HC-128 dhardy/rand#53New iterator codeRng::iter #275 rejected; Deprecate gen_iter and add iteration examples #286 mergedDesired additions:
Bernoulli
distribution andgen_bool
then deprecategen_weighted_bool
(see ReviseRng
methods #293)Finally, a list of other planned changes, which probably won't make 0.5:
gen_ascii_chars
withAlphanumeric
distribution: Add Alphanumeric distribution #279SeedableRng::from_hashable
: Seeding PRNGs (traits and bit size) dhardy/rand#18, SeedableRng::Seed and from_hashable dhardy/rand#62StdRng
: Replace ISAAC with HC-128 dhardy/rand#53weak_rng
: Requirements for a small fast RNG dhardy/rand#60, Shootout: small, fast PRNGs dhardy/rand#52XorShiftRng
,IsaacRng
,ChaChaRng
, etc. fromrand
(don't export): To provide (or not) specific PRNGs? dhardy/rand#58WeightedChoice
& sequences code: Sequence sampling:seq
,WeightedChoice
dhardy/rand#82Rng
methods #293, Deprecate gen_iter and add iteration examples #286, Add Alphanumeric distribution #279The text was updated successfully, but these errors were encountered: