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

Faster each permutation #5127

Closed
wants to merge 2 commits into from

Conversation

tmmcguire
Copy link
Contributor

This is a replacement each_permutation that is somewhat faster than the previous version (and 2x faster, according to my testing, than the versions on the mailing list in January). The algorithm is based on "Generation in lexicographic order" section in Wikipdedia (http://en.wikipedia.org/wiki/Permutation#Generation_in_lexicographic_order).

I also exposed a function to reverse a portion of a vector which is used by the algorithm and seems like it might be something someone would want.

Finally, there's a each_permutation_ref that eliminates the Copy type requirement.

@catamorphism
Copy link
Contributor

A pull request generally shouldn't contain merge commits -- can you update your copy of the rust incoming branch and then rebase your branch off incoming and force-push (push -f) to your branch? That should get rid of the merge commits.

@tmmcguire
Copy link
Contributor Author

On 02/26/2013 03:58 PM, Tim Chevalier wrote:

A pull request generally shouldn't contain merge commits -- can you
update your copy of the rust incoming branch and then rebase your branch
off incoming and force-push (|push -f|) to your branch? That should get
rid of the merge commits.

Thanks! That looks much better.

Tommy M. McGuire
mcguire@crsr.net

@bstrie
Copy link
Contributor

bstrie commented Mar 4, 2013

@tmmcguire I believe that pcwalton was just remarking on the comment Behavior is undefined if start or end do not represent valid with the observation that the behavior was actually defined to fail, rather than being undefined. :) I see that you've changed this behavior in the most recent commit; I'm not actually sure whether this function ought to fail or not.

@tmmcguire
Copy link
Contributor Author

On 03/04/2013 01:51 PM, Ben Striegel wrote:

@tmmcguire https://github.com/tmmcguire I believe that pcwalton was
just remarking on the comment |Behavior is undefined if start or end do
not represent valid| with the observation that the behavior was actually
defined to fail, rather than being undefined. :) I see that you've
changed this behavior in the most recent commit; I'm not actually sure
whether this function ought to fail or not.

That makes sense. I thought he was talking about something related to
the bors comment, "merging tmmcguire/rust/faster_each_permutation =
dba7f6d into auto failed".

To tell the truth, I don't know whether it ought to fail or not, either,
but failing does make debugging uses of it easier. :-)

Tommy M. McGuire
mcguire@crsr.net

@brson
Copy link
Contributor

brson commented Mar 11, 2013

Let's please make it fail on bad input instead of silently returning. That is consistent with other functions in core.

@Aatch
Copy link
Contributor

Aatch commented Apr 29, 2013

Looks like this is still valid, @tmmcguire are you going to complete this or should I close?

@bors bors closed this in 77c98f0 May 18, 2013
bors added a commit to rust-lang-ci/rust that referenced this pull request May 2, 2020
improve 'iter_nth_zero' documentation

closes rust-lang#5115

changelog: Improve the documentation of `iter_nth_zero`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants