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

Implement RFC #2169 (Euclidean modulo). #49389

Merged
merged 5 commits into from Apr 13, 2018

Conversation

Projects
None yet
6 participants
@fanzier
Copy link
Contributor

fanzier commented Mar 26, 2018

Tracking issue: #49048

@rust-highfive

This comment has been minimized.

Copy link
Collaborator

rust-highfive commented Mar 26, 2018

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @KodrAus (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@varkor
Copy link
Member

varkor left a comment

This is looking good! I've left a few very minor comments, but apart from that and fixing the tidy errors, I can't see any problems!

@@ -1318,6 +1460,40 @@ $EndFeature, "
}
}


doc_comment! {
concat!("Calculates the modulo of Euclidean divsion `self.mod_euc(rhs)`.

This comment has been minimized.

@varkor

varkor Mar 26, 2018

Member

Nit: I would call this "the remainder" or "the modulus", as "modulo" is the operation, rather than the result.

This comment has been minimized.

@fanzier

fanzier Mar 27, 2018

Author Contributor

Changing to "remainder" since "modulus" is another word for "divisor".



doc_comment! {
concat!("Calculates the modulo `self mod rhs` by Euclidean division.

This comment has been minimized.

@varkor

varkor Mar 26, 2018

Member

And here.

doc_comment! {
concat!("Calculates the quotient of Euclidean division of `self` by `rhs`.
This computes the integer n such that `self = n * rhs + self.mod_euc(rhs)`.

This comment has been minimized.

@varkor

varkor Mar 26, 2018

Member

Nit: backticks around n for consistency (and in f32/f64).

#[unstable(feature = "euclidean_division", issue = "49048")]
#[inline]
pub fn wrapping_div_euc(self, rhs: Self) -> Self {
self.div_euc(rhs)

This comment has been minimized.

@varkor

varkor Mar 26, 2018

Member

This can be the standard self / rhs to avoid the extra branch (like with wrapping_mod_euc).

This comment has been minimized.

@fanzier

fanzier Mar 27, 2018

Author Contributor

Good catch, thanks.

@varkor

varkor approved these changes Mar 27, 2018

Copy link
Member

varkor left a comment

Looks good to me 👍

@fanzier

This comment has been minimized.

Copy link
Contributor Author

fanzier commented Mar 27, 2018

I was just wondering whether the f32/f64 code should live in libstd or in libcore. Since it doesn't depend on anything special, I think it should be in core, not std. On the other hand, there is a lot of stuff in libstd/f32.rs that I would have guessed should be in libcore/num/f32.rs. What is the policy regarding this?

@varkor

This comment has been minimized.

Copy link
Member

varkor commented Mar 28, 2018

As far as I'm aware, the libstd methods are limited to those that rely on platform libraries / intrinsics (e.g. most of the mathematical methods). Pure-Rust methods tend to reside in libcore (which also makes them available for no_std). I wouldn't be surprised if the situation isn't entirely consistent at the moment.

I think libcore was the correct choice here.

Edit: just realised the floating-point methods are not in libcore right now. See later comment.

@fanzier

This comment has been minimized.

Copy link
Contributor Author

fanzier commented Mar 28, 2018

@varkor That makes sense. So I should move the float methods to libcore?

Edit: Apparently, to move it there, I would have to add the div_euc and mod_euc methods to the num::Float trait, which seems like overkill. Let's keep it as is?

@varkor

This comment has been minimized.

Copy link
Member

varkor commented Mar 28, 2018

I got a little confused before, sorry! I think it would be better to move the methods to libcore and delegate to them in libstd, yes (see, for example, the relatively recent to_bits, which does the same). You will have to extend the Float trait, but this should also allow the methods to be used on no_std, which is useful and expected. (It's not like the Float trait is being kept deliberately minimal as far as I can tell.)

@fanzier

This comment has been minimized.

Copy link
Contributor Author

fanzier commented Mar 28, 2018

Fair enough, I'll move it into libcore. But since div_euc uses f32::trunc, should I move trunc from libstd into num::Float as well, or use intrinsics::truncf32 directly instead?

@varkor

This comment has been minimized.

Copy link
Member

varkor commented Mar 28, 2018

But since div_euc uses f32::trunc, should I move trunc from libstd into num::Float as well, or use intrinsics::truncf32 directly instead?

Ah, I didn't spot that. In that case, let's just leave it in libstd for now. If anyone needs it in libcore later on, it can be moved then (unless anyone else has some strong opinions now?). I think the integer methods are the most important ones, anyway.

@shepmaster

This comment has been minimized.

Copy link
Member

shepmaster commented Apr 7, 2018

Ping from triage, @KodrAus ! Will you have time to review soon?

@KodrAus
Copy link

KodrAus left a comment

Sorry for the late review! This is looking good, thanks @fanzier. I've just left a few nitpicky comments about the docs. Once we're happy with those I think we can push this through.

concat!("Wrapping Euclidean division. Computes `self.div_euc(rhs)`,
wrapping around at the boundary of the type.
The only case where such wrapping can occur is when one divides `MIN / -1` on a signed type (where

This comment has been minimized.

@KodrAus

KodrAus Apr 12, 2018

The wording here feels a little wonky. How about:

Wrapping will occur in MIN / -1 on a signed type (where MIN is the negative minimal value for the type). This is equivalent to -MIN, a positive value that is too large to represent in the type. In this case, this method returns MIN itself.

This comment has been minimized.

@fanzier

fanzier Apr 12, 2018

Author Contributor

I almost copy-pasted that documentation from wrapping_div. Should I update the documentation there as well or should that be a separate PR?

concat!("Wrapping Euclidean modulo. Computes `self.mod_euc(rhs)`, wrapping around at the
boundary of the type.
Such wrap-around never actually occurs mathematically; implementation artifacts make `x % y`

This comment has been minimized.

@KodrAus

KodrAus Apr 12, 2018

Same as above. How about:

Wrapping will occur in MIN % -1 on a signed type (where MIN is the negative minimal value for the type). In this case, this method return 0.

concat!("Calculates the quotient of Euclidean division `self.div_euc(rhs)`.
Returns a tuple of the divisor along with a boolean indicating whether an arithmetic overflow would
occur. If an overflow would occur then self is returned.

This comment has been minimized.

@KodrAus

KodrAus Apr 12, 2018

We should put self in backticks here.

@KodrAus

This comment has been minimized.

Copy link

KodrAus commented Apr 13, 2018

Thanks @fanzier this looks good to me! I'll leave a note on the tracking issue about libcore vs libstd.

@bors r+

@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 13, 2018

📌 Commit ca4e458 has been approved by KodrAus

@KodrAus KodrAus referenced this pull request Apr 13, 2018

Open

Tracking issue for RFC 2169: Euclidean Modulo #49048

1 of 2 tasks complete
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 13, 2018

⌛️ Testing commit ca4e458 with merge f9f9050...

bors added a commit that referenced this pull request Apr 13, 2018

Auto merge of #49389 - fanzier:euclidean-division, r=KodrAus
Implement RFC #2169 (Euclidean modulo).

Tracking issue: #49048
@bors

This comment has been minimized.

Copy link
Contributor

bors commented Apr 13, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: KodrAus
Pushing f9f9050 to master...

@bors bors merged commit ca4e458 into rust-lang:master Apr 13, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details

@scottmcm scottmcm referenced this pull request Apr 18, 2018

Open

Tracking issue for integer methods for Wrapping #32463

12 of 23 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.