-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
mutating APIs for BigInts and BigFloats? #31342
Comments
For experimental API. Compiler optimizations are more important long term, but I think we should do something immediately to make Something that could work directly (using current lowering) is syntax like |
For reference, I wrote InPlace.jl precisely to be able to take advantage of in-place bignum operations. |
has there been any movement on this issue? the default arithmetic for BigInts being slow seems like a major usability issue for number theorists, etc. I know Nemo implements its own fast arithmetic for Flint multiprecision ints, but it'd be nice to have this functionality as the default behavior |
The MutableArithmetics package might be useful to people who come upon this issue: |
We have
Base.GMP.MPZ.add!
and other very internal mutating arithmetic operations forBigInt
s which are used internally within theBigInt
implementation to implement faster versions of some operations. #31310 introducesBase.MPFR.nextfloat!
andBase.MPFR.prevfloat!
as some of the first internal mutating functions forBigFloat
s. This PR also raises the question of what the API for copying a bignum should be—this is fundamentally part of the same API design question since without mutation there's never any point in copying a bignum.Should we have a more coherent mutating API for both
BigInt
s andBigFloat
s? The general guidance for using such a mutating API should probably be that you should only using the mutating operations on bignums when you "own" the bignum in the sense that you're sure that only your code can observe the mutation.Is this a good idea? Should we avoid this and instead focus on better compiler tech to allow writing non-mutating bignum code and having the compiler reuse bignum objects as necessary? One of the concerns about introducing a mutating API is that needing to support it could potentially prevent such optimizations or make them harder. Perhaps the mutating API could be an experimental API that we might remove in the future.
The text was updated successfully, but these errors were encountered: