CPython 3.13: add _PyLong_New() and import some macros from pycore_hash.h #441
Conversation
Codecov Report
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. @@ Coverage Diff @@
## master #441 +/- ##
=======================================
Coverage 83.41% 83.41%
=======================================
Files 49 49
Lines 11797 11797
Branches 2205 2205
=======================================
Hits 9841 9841
Misses 1956 1956
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
…sh.h Turn on basic tests on 3.13 Closes aleaxit#417
skirpichev
force-pushed
the
fix-for-cpython3.13
branch
from
0510858 to
1edb036
Compare
|
I think we should decide which C-API we need. I would guess, something like mpz_limbs_read/mpz_limbs_write - i.e. access to the internal |
|
Thanks for fixing this. Regarding a C-API that would be nice to have, I what do you think about proposing that CPython provides suitably renamed functions |
|
@casevh, maybe something like this, yes. I still feel CPython people should try gmp-like API, as mentioned above. I'll open an issue or start a discussion thread in d.p.o. Before, I'll look into more projects that may need this kind of stuff, besides gmpy2 and cython. Sage, perhaps? @oscarbenjamin, would you like to have this type of interface for python flint bindings? So far e.g. I see fmpz_get_intlong() do fmpz->int conversion using strings. |
|
The existing PyLong uses a sign/magnitude format using either 15 or 30 bits
per limb. GMP uses sign/magnitude with either 32 or 64 bits per limb. (At
least on the platforms that are relevant to this discussion.) I think any
sign/magnitude format that has a defined structure and relies on commonly
available C types (i.e. uint32 or uint64 or equivalent) for the limbs would
be fine. I wouldn't be surprised if CPython adopts 60 bits per limb in the
future. to_bytes() and from_bytes() is a useful external interface but an
arbitrary-precision 2s-complement format isn't the most efficient for
conversion between two similar sign/magnitude formats.
…On Tue, Oct 24, 2023 at 10:13 PM Sergey B Kirpichev < ***@***.***> wrote:
@casevh <https://github.com/casevh>, maybe something like this, yes. I
still feel CPython people should try gmp-like API, as mentioned above.
I'll open an issue or start a discussion thread in d.p.o. Before, I'll
look into more projects that may need this kind of stuff, besides gmpy2 and
cython. Sage, perhaps? @oscarbenjamin <https://github.com/oscarbenjamin>,
would you like to have this type of interface for python flint bindings? So
far e.g. I see fmpz_get_intlong() do fmpz->int conversion using strings.
—
Reply to this email directly, view it on GitHub
<#441 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMR235N2AD7HUSL6M4WYOTYBCNZPAVCNFSM6AAAAAA6LM6E5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZYGUZDMNJWHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yes, I think so. There is a PR here to try to optimise converting from a CPython int: flintlib/python-flint#64 Also efficient conversions between python-flint and gmpy2 would be good: flintlib/python-flint#56 What would be nice is if there was somehow a general API for doing this with any arbitrary precision integer type so that efficient conversions could be done for any of them rather than needing special casing for each type. |
|
python/cpython#102471 seems to be the right upstream issue |
Turn on basic tests on 3.13
Closes #417