Open skirpichev opened 6 days ago
I like this idea. I've thought about it but don't have the time to implement it. I have a system with lots of memory that I can use for stress testing.
I'm thinking about a separate package (something like gmp-python, as flint-python; better name?), which will provide such mpz type and few integer-related functions (like isqrt). This type will have int-compatible interface. (Revival of https://github.com/python/cpython/issues/66121-like patch is also in my short-term plans.)
Later we can include this to gmpy2's mpz. I don't think that testing memory handling will require a machine with a lots of memory (e.g. in Linux you can emulate more tight memory bounds with ulimit). By I would appreciate more testing anyway!
A separate package does make sense for me also because other projects (e.g. mpmath, sympy or diofant) use only integer-related stuff from the gmpy2 (well, maybe mpq's too). Now python ecosystem has much better handling of dependencies. So, eventually it might be useful to split the gmpy2 package to two or three. This is a different issue, however. Let me know if it does make sense for you.
POC pr for CPython: https://github.com/python/cpython/issues/66121
I think we can adopt similar strategy to implement arithmetic operations for mpz/xmpz's. No need to change MPZObject structure. All we need: appropriately allocate/reallocate/free memory by hand and use low-level mpn* functions to operate on arrays of limbs. I don't expect any speed loss.
On pros: arithmetic on mpz's will never crash the interpreter. (That might be the case for some special function, but not for the basic stuff, working on CPython int's.) New mpz's could be used as a drop-in replacement for int's.