-
Notifications
You must be signed in to change notification settings - Fork 135
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
Add support for euclidean division and modulation #195
Conversation
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.
I think we can use FloatCore
to avoid the cfg
limitations. Otherwise, there are some style issues, but I think this looks pretty good!
Thanks very much for reviewing. I have made the corresponding changes. |
src/ops/euclid.rs
Outdated
($($t:ty)*) => {$( | ||
impl Euclid for $t { | ||
#[inline] | ||
fn div_euclid(self, v: $t) -> Self { |
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.
Any reason for this to not use the corresponding method on all integer types?
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.
That's what I did before. But this will cause the test of version 1.8.0 to fail, as it shows that the parameter type of div_eculid/rem_eculid is incorrect (expecting &self, not self, or on the contrary). So I implemented a separate implementation to avoid these compatibility issues.
@cuviper Is there anything left in this PR that needs to be changed? We'd really like this functionality for |
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.
I think the methods should take references, for the sake of num-bigint
where it's a waste of allocations to consume values. Either that, or go fully generic with a type parameter RHS and and associated type Output
, so they can be implemented for any mix of values and references. There are annoyance trade-offs both ways.
I think it is reasonable to use reference types from the aspect of efficiency. If a general type is used and the Output type is specified, we need to implement it separately for the several cases(self, &self, rhs, &rhs). This should probably be what a direct user-facing library should do. As a basic library, num-trait should maintain its concise style IMO |
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, it looks nice.
Maybe we should also add a combined div_rem_euclid
? (and checked.) That would let you get both values with the divisions and conditions only checked once. All that probably gets optimized together with primitive values anyway, but it would matter for types like BigInt
.
28aeb95
to
3d93495
Compare
3d93495
to
18575c2
Compare
bors r+ |
245: Implement Euclid division and remainder r=cuviper a=jaybosamiya Now that a common trait for this has been sorted out (rust-num/num-traits#159 implemented and merged in rust-num/num-traits#195), we can now close #146 by implementing the trait for `BigInt`s. This commit does just that. Co-authored-by: Jay Bosamiya <jaybosamiya@gmail.com> Co-authored-by: Josh Stone <cuviper@gmail.com>
245: Implement Euclid division and remainder r=cuviper a=jaybosamiya Now that a common trait for this has been sorted out (rust-num/num-traits#159 implemented and merged in rust-num/num-traits#195), we can now close #146 by implementing the trait for `BigInt`s. This commit does just that. Co-authored-by: Jay Bosamiya <jaybosamiya@gmail.com> Co-authored-by: Josh Stone <cuviper@gmail.com>
Fixes #159
Add support for euclidean division and modulation.