-
Notifications
You must be signed in to change notification settings - Fork 308
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
Complete Permutations::size_hint
#739
Complete Permutations::size_hint
#739
Conversation
Known/Overflow variants have the advantage of the readability but it's less handy than options. A doc comment seems enough to me to say that None means it would overflow.
Clearer. And `prefill` extending the buffer seems better performance wise than push items to the buffer one by one with `get_next`.
We are at the very beginning. We prefilled `k` values, but did not generate any item yet. There are `n!/(n-k)!` items to come (safely done in remaining). But `n` might be unknown.
We generated `prev_iteration_count` items (`n` still unknown). So the same as `PermutationState::StartUnknownLen` minus `prev_iteration_count`.
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.
Thank you for this!
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.
Ideally, the lower bound of the size hint would remain `usize::MAX` but I don't see how we could make this happen. Small bugfix: `n+1` might overflow.
bors r+ |
Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
@phimuemue
This series of size hint/count improvements ends where it started: with a TODO I wanted to fix.
The end user will mostly enjoy that
(0..n).permutations(k).map(...).collect_vec()
will now allocate to the resulting vector in one go (PermutationState::StartUnknownLen
case).In the first commit, you probably will want me to unwrap but
panic!(message)
is more similar toexpect
thanunwrap
. Which is why I previously usedexpect
too.The 2nd commit (about
enough_vals
) is off topic but I really don't see why it would not be a (minor) improvement.I have a test
permutations_inexact_size_hints
ready if you want (similar tocombinations_inexact_size_hints
).