Add utilities for modular arithmetic #320
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These utilities all operate on unsigned 64-bit integers. The main design goal is to produce correct answers for all inputs while avoiding overflow. Most operations are standard: addition, subtraction, multiplication, powers. The one non-standard one is "half_mod_odd". This operation is `(x/2) % n`, but only if `n` is odd. If `x` is also odd, we add `n` before dividing by 2, which gives us an integer result. We'll need this operation for the strong Lucas probable prime checking later on. These are Au-internal functions, so we use unchecked preconditions: as long as the caller makes sure the inputs are already reduced-mod-n, we'll keep them that way. Helps #217.
chiphogg
added
the
release notes: ♻️ lib (refactoring)
geoffviola
requested changes
Nov 8, 2024
The new test would fail without this change!
geoffviola
approved these changes
Nov 8, 2024
| // | ||
| // Precondition: (a < n). | ||
| // Precondition: (n is odd). | ||
| constexpr uint64_t half_mod_odd(uint64_t a, uint64_t n) { |
There was a problem hiding this comment.
Can we document this a little more? If a < n, then a / 2 < n. So (a / 2) % n would just be a.
| // | ||
| // Precondition: (a < n). | ||
| // Precondition: (b < n). | ||
| constexpr uint64_t mul_mod(uint64_t a, uint64_t b, uint64_t n) { |
There was a problem hiding this comment.
This implementation seems right. It gets the right answer for the JUST_UNDER_HALF, 10u, MAX case as opposed to https://www.geeksforgeeks.org/how-to-avoid-overflow-in-modular-multiplication/
There was a problem hiding this comment.
Geeksforgeeks has such terrible quality control. I also stumbled on this supposed Baillie-PSW implementation, which is very clearly only the Miller-Rabin step! (Not to mention: their modPow implementation runs in O(exp) rather than O(log(exp)). Bring a pillow!)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These utilities all operate on unsigned 64-bit integers. The main
design goal is to produce correct answers for all inputs while avoiding
overflow.
Most operations are standard: addition, subtraction, multiplication,
powers. The one non-standard one is "half_mod_odd". This operation is
(x/2) % n, but only ifnis odd. Ifxis also odd, we addnbefore dividing by 2, which gives us an integer result. We'll need this
operation for the strong Lucas probable prime checking later on.
These are Au-internal functions, so we use unchecked preconditions: as
long as the caller makes sure the inputs are already reduced-mod-n,
we'll keep them that way.
Helps #217.