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

Consider adding an owned version of WeightedChoice #90

Closed
mneumann opened this issue Dec 30, 2015 · 9 comments
Closed

Consider adding an owned version of WeightedChoice #90

mneumann opened this issue Dec 30, 2015 · 9 comments
Labels
F-new-int Functionality: new, within Rand

Comments

@mneumann
Copy link

This can more easily embedded within any other type, than the WeightedChoice type.

https://github.com/mneumann/graph-annealing/blob/master/src/owned_weighted_choice.rs

Or, maybe better would be to add code to reuse some code of weighted_choice?

@keisetsu
Copy link

I would really like to see this, too.

@mbrubeck
Copy link
Contributor

I think it might even be better to provide only an owned version. The borrowed version does not seem to provide many useful advantages over an owned version. For example, you can't re-use the [Weighted<T>] slice after the borrow ends, because it has been mutated and no longer contains the same weights. This is a potential foot-gun too, since it leaves the [Weighted<T>] around in an unspecified state, easy to mis-use. Better to consume it and prevent such bugs.

On the other hand, the borrowed version allows building a WeightedChoice from a temporary stack array without allocating. Changing it to own a Vec<Weighted<T>> would prevent this...

@ramn
Copy link

ramn commented May 22, 2017

I changed to this, which passes the test suite:

pub struct WeightedChoice<T: AsMut<[Weighted<U>]> + AsRef<[Weighted<U>]>, U: Clone> {
    items: T,
    weight_range: Range<u32>,
    _phantom: marker::PhantomData<U>,
}

But it looks a bit crazy.

@ramn
Copy link

ramn commented May 22, 2017

Opened a PR #151 to get the ball rolling.

@mbrubeck
Copy link
Contributor

Heh, I submitted PR #152 which takes a different approach, adding a new owned type while leaving the existing type unchanged. The main advantage of #152 is that it is not a breaking change. The disadvantage is that it adds a redundant type and impls.

@ramn
Copy link

ramn commented May 22, 2017

Haha quick work! Yes yours looks more proper, and non-breaking!

@ramn
Copy link

ramn commented May 22, 2017

Hm build failed for mine, but cargo test locally works fine

@ramn
Copy link

ramn commented May 22, 2017

Not an argument for my specific implementation, but one could argue that the current version of WeightedChoice is not very idiomatic and perhaps should be retired. The design seems awkward.

@alexcrichton alexcrichton added the F-new-int Functionality: new, within Rand label Jun 14, 2017
dhardy added a commit to dhardy/rand that referenced this issue Jul 29, 2017
The change to WeightedChoice is debatable, but since the argument must normally
be constructed specially anyway, the reference model makes little sense.
See issues rust-random#90, rust-random#142 and PR rust-random#152.
rfdonnelly added a commit to rfdonnelly/rvs that referenced this issue Jan 8, 2018
Notable changes:

* transform::rand::Seed got simpler
* Misc minor API differences
* Swap out rand::distributions::WeightedChoice with custom
  WeightedIndexes type

  WeightedChoice for released version of rand does not own the array it
  operates on.  Because of this, it is not possible to keep around an
  instance of WeightedChoice and reuse its internal range.  The
  experimental version of rand resolves this but it cannot be used by
  published crates.  Fix by rolling our own WeightedIndexes type.

  See rand issues:
  * rust-random/rand#90
  * rust-random/rand#142
@sicking
Copy link
Contributor

sicking commented Jul 22, 2018

This API was deprecated and replaced with a new API in #518 which I think fixes this.

@dhardy dhardy closed this as completed Jul 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-new-int Functionality: new, within Rand
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants