-
Notifications
You must be signed in to change notification settings - Fork 311
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
Specialize CombinationsWithReplacement::nth
#923
Specialize CombinationsWithReplacement::nth
#923
Conversation
Steal how `next` increment indices, a bit improved. It will soon be used in `nth` (and more later).
Use the new `increment_indices`. This is done in a different commit because the git difference was difficult to read.
Use `pool.get_at` once! That way, `next` and `nth` will ressemble each other.
Similar to `next` except we increment indices n times before generating the vector item.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #923 +/- ##
==========================================
+ Coverage 94.38% 94.51% +0.12%
==========================================
Files 48 48
Lines 6665 6890 +225
==========================================
+ Hits 6291 6512 +221
- Misses 374 378 +4 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Philippe-Cholet. I think it's technically correct, although I'd rewrite some parts. If you like your proposal better, fine with me.
Should we extract the "initialization" part into an own function?
210e6e4
to
a250651
Compare
Similarly to #914, I reorder
CombinationsWithReplacement::next
then specializeCombinationsWithReplacement::nth
.Benchmarks similar to #916 (comment)
I did not expect
next
to be a bit faster but I'm not complaining..nth(0)
is a little bit slower but other.nth(..)
s are faster, closely following allocations changes.