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

ACP: isqrt for NonZero<uN> #391

Closed
ivan-shrimp opened this issue Jun 10, 2024 · 4 comments
Closed

ACP: isqrt for NonZero<uN> #391

ivan-shrimp opened this issue Jun 10, 2024 · 4 comments
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api

Comments

@ivan-shrimp
Copy link

Proposal

Problem statement

Integer primitives now have an integer square root method isqrt. Positive integers always have a positive square root, and it would be natural to directly express this through NonZero.

Motivating examples or use cases

x.pow(2).isqrt() gives x for x: uN, and we can extend that to NonZero<uN>.

Solution sketch

// N = 8/16/32/64/128/size
impl NonZero<uN> {
    const fn isqrt(self) -> Self {
        // should behave as if:
        unsafe { NonZero::new_unchecked(self.get().isqrt()) }
    }
}

Alternatives

  • Do nothing, and require users to use the NonZero constructors manually when necessary. This is either unsafe or requires .unwrap(), which is not ideal.
  • Halve the size of the returned integer. However, this would be inconsistent with the primitive counterparts and violate the round-tripping property as mentioned above.

Links and related work

Motivation for primitive isqrt: rust-lang/rust#89273
Tracking issue for isqrt: rust-lang/rust#116226
Suggestion for this function: rust-lang/rust#116226 (comment)
Implementation: rust-lang/rust#126199

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

  • We think this problem seems worth solving, and the standard library might be the right place to solve it.
  • We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

  • We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
  • We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.
@ivan-shrimp ivan-shrimp added api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api labels Jun 10, 2024
@kennytm
Copy link
Member

kennytm commented Jun 10, 2024

My motivation suggesting NonZero<uN>::isqrt() in rust-lang/rust#116226 (comment) was that, given a natural number $N &gt; 0$, compute the "middle" value $M = \lfloor\sqrt N\rfloor &gt; 0$ to decompose every number $i \in \mathbb Z_N$ into $(a,b) \in \mathbb Z_{\lceil N/M\rceil} \times \mathbb Z_M$ with $i = aM b$. The $(a,b)$ pair is then feed through a Feistel network in order to perform something like format-preserving encryption.

With N: NonZero<u64> we can use NonZero::isqrt() to get M: NonZero<u64> so that (a, b) = (i / M, i % M) are panic-free.

@scottmcm
Copy link
Member

(Disclaimer: I'm not libs-api) This seems entirely reasonable to me, under the same "it's helpful compared to .get().isqrt()" that gave us NonZero::count_ones and NonZero::ilog2.

@pitaj
Copy link

pitaj commented Jun 10, 2024

For the future, the following operations could have the same function signature fn(NonZero<T>) -> NonZero<T>

  • reverse_bits
  • rotate_left
  • rotate_right
  • swap_bytes
  • to_be
  • to_le

@the8472
Copy link
Member

the8472 commented Jun 11, 2024

We discussed this during today's libs-api meeting and adding isqrt was accepted.
Additional methods should go in a separate ACP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ACP-accepted API Change Proposal is accepted (seconded with no objections) api-change-proposal A proposal to add or alter unstable APIs in the standard libraries T-libs-api
Projects
None yet
Development

No branches or pull requests

5 participants