-
Notifications
You must be signed in to change notification settings - Fork 192
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove big_digit::* from the public API
The *idea* of `big_digit` and its type aliases is that we may someday use something other than `u32` in the representation, perhaps even different sizes for different targets. That's still a possibility, but I think it's not really feasible to expose this variation in the public API. Calling `BigUint::from_slice([1, 2, 3])` is only meaningful if you know what that size is, and users can't really alternate this kind of thing based on a type definition. So for now, we just commit to `u32` units in the public API, no matter what we may do internally. This removal is a breaking change, part of the 0.2 semver bump. If I'm wrong and somebody can show a compelling use case for `big_digit`, we can always add things back into the public API later.
- Loading branch information
Showing
9 changed files
with
108 additions
and
112 deletions.
There are no files selected for viewing
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
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
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
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
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
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
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
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
Oops, something went wrong.
a849284
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.
@cuviper Is it possible to only expose the
BigDigit
type without changing the API? The use case in my situation is that I want to implement a general implementation of Montgomery multiplication (for various number theoretic functions). If the related functionmontgomery
can be exposed (which requiresBigDigit
to be exposed), I can reduce a lot of redundant code!I agree that users should not depends on the size of BigDigit when creating new big integers, however it doesn't hurt to expose the BigDigit type and some low level algorithms for other algorithms that work on big integers (just like
mpn
functions in GMP)a849284
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.
@cmpute
BigDigit
is a type alias, and I'm pretty firm that I don't want to expose that as it flips betweenu32
oru64
. We could possibly expose an opaque wrapper type. In the particular instance of themontgomery
function, it might make sense to publicizeMontyReducer
and itsnew
constructor, as well as amontgomery
method on that type.a849284
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 for the reply! That would be great if
MontyReducer
could be exposed. But how will that work if BigDigit is not exposed? The montgomery method depends on the modular inversek
, which has to be the size of aBigDigit
a849284
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.
My motivation for this is actually implementing this trait in my
num-modular
trait to support various operations in Montgomery form