Faster each permutation

[tmmcguire]

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]

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]

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
[email protected]

[bstrie]

@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]

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
[email protected]

[brson]

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

[Aatch]

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