-
Notifications
You must be signed in to change notification settings - Fork 1
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
Req. normalized arbitrary integer elements #26
Comments
BinaryInteger/isZero was the first use case I thought of, but I suppose I could improve it be checking the appendix bit first and performing the comparison backwards. I'm sure there are other use cases, however. Edit: I suppose BinaryInteger/isZero would still improve somewhat since it would compare zero elements instead of one or zero elements (backwards). At the same time, big integers are kind of slow by definition so I would not put much emphasis on an element comparison. |
This changes makes DataInt/isZero an O(1) operation for normalized instances because the last element of a normalized instance must not be zero when the appendix is zero.
Another unnecessary normalization is found in BinaryInteger.random(in:using:)'s arbitrary integer path, more specifically in one of the internal Randomness algorithms. |
My primary concern is that normalized elements may not be normalized after you reinterpret them, which this project does a lot. It could be surprising if elements and elements-as-type behave differently. Also, the performance improvement is small. |
Idea: generic algorithms would never need to perform conservative normalization checks or transformations in big integer branches if big integers are required to offer normalized elements. InfiniInt<T> already does this because it would be silly to do otherwise, but generic algorithms cannot yet assume it.
The text was updated successfully, but these errors were encountered: