-
Notifications
You must be signed in to change notification settings - Fork 27
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
Trouble Installing Latest Version of python-flint via pip #193
Comments
Indeed it is. Okay, so there are a few issues here. The first is that binary wheels are provided for many common platforms but not for Linux aarch64 (gh-105) which I'm assuming is your platform. Are you on Linux aarch64? Those wheels will hopefully be added soon, but we're basically waiting for GitHub Actions to provide the runners that could build and test them. The second issue is that building from source with the current release (0.6.0) uses setuptools which does not check the Flint version. Can you try installing the latest prerelease with one of: pip install --pre python-flint
pip install python-flint==0.7.0a4 I would be interested to know what output you see but I hope it will be something like:
The fact that it can check the Flint version is because the build system has changed from setuptools to meson and meson can check the version and fail the build. Oh, actually no it won't because we're not checking it here: Line 10 in 162ded1
It should be something like:
Probably 3.2 is already compatible (we have a CI check against Flint main branch). I'm not sure how to manage an upper cap on the version here. When 3.1 came out it was not compatible (prior versions of python-flint would have failed to build). I expect that the same would happen with 3.2 because it only takes one small change to break the build so realistically each new Going forwards I would like to keep 3.0 as the minimum supported Flint version for as long as possible but there were big changes in 3.0 and it didn't make sense to try to support both I think that then is the actual problem although I may be wrong. You need Flint 3.0 was released about 18 months ago I think? So it's pretty new. You either need to build Flint from source or you can maybe get it in a distro binary. The only distro version I know of that provides Flint 3.0 is Ubuntu 24.04 (released a few months ago). On that distro you can install Flint 3.0.1 with:
That is tested in CI although not on aarch64 (no CI runners available): python-flint/.github/workflows/buildwheel.yml Lines 123 to 139 in 162ded1
|
Thank you for the quick reply! Yes, I am on Linux AArch64. Running
I also tried installing version 0.5.0, as you suggested this may be at the boundary of where the problem is, relating to the version of Flint, and ran into the following error message:
However, when I tried to install version 0.4.4, I ran into a similar error to the 0.5.0 message:
In all three cases the error was |
What version of Flint do you have? My guess it is that it is an old enough version that it just doesn't provide a
I think that with these versions of python-flint the issues you see are to do with not have the correct versions of things like cython. Now python-flint has a pyproject.toml: Lines 1 to 3 in 162ded1
We should probably put a constraint on the Cython version. At least Cython >= 3.0 is needed for current python-flint I think.
If you want to try building those previous versions then you would need to use something like:
Unfortunately I don't remember what the necessary Cython version was back in 0.4.4... You can see the list of Cython releases here:
They are useful. No they are not to do with aarch64. The error messages are hard to understand because you have pip calling itself in an isolated environment that then calls cython in another subprocess and so you get this Russian doll error message inside error message situation. If you know how to parse the error messages then the relevant parts are: For Flint 0.7.0a4 the error message is:
This is because you don't have a new enough version of Flint. In fact your Flint is too old for meson to find it (no flint.pc) let alone report the version failure. For Flint 0.4.4 and 0.5.0 the error message is:
This is Cython failing to compile python-flint's cython code. I think that this is because an older version of Cython is being used or possibly it is that newer Cython does not work with older python-flint or something. Basically you don't have the right version of cython for that particular version of python-flint. If you were to fix it then I would expect that 0.5.0 would fail with the same missing header error as 0.6.0 but hopefully 0.4.4 would work (although that still requires some minimum Flint version and you haven't said what version of Flint you have). All of these things are going to be much improved in 0.7.0 with meson as the build system and pyproject.toml with version constraints. The pyproject.toml will ensure correct versions of build requirements like Cython and the meson build system will properly detect required C compilers and version of Flint. That should mean that you either get a clear error for unsupported Flint versions (or missing C compilers) or that you get a successful build. However to use any python-flint newer than 0.4.4 you will need to use at least Flint 3.0. You haven't said what Flint version you have but I am fairly sure that is the source of the problem that prevents that latest version of python-flint from compiling on your machine. So the solution to your problem is either:
|
In parallel I have been making a pull request (gh-194) that will check the Flint version properly so that for 0.7.0 only tested versions of Flint will be accepted and hopefully the error message will be improved to look like this one:
|
I realize I was actually able to run Flint without going to the website to download it because of another piece of software I use, CYTools. As Flint was installed in my instillation of CYTools, I'm not precisely sure what underlying version I am using is; is there a way to query for this in python? Running Edit: in Given the unique function names and such within Flint, as well as minimal outside dependencies, I would imagine that installing the newer version of Flint would not affect the functionality of the CYTools package (outside of new function names/usages). However, I'm unsure as to whether I would need to find where Flint was downloaded within CYTools, uninstall it there, redownload a newer version, and proceed, or if I could just go to the Flint website and download the newest version available.
and the reinstall message:
the version printed via Edit: in Thank you for helping answer these questions! When I know how, I will try to install a newer version of Flint to see if |
There is a way to get the Flint version from python-flint but er... only in python-flint 0.6.0 :) In [1]: import flint
In [2]: flint.__version__
Out[2]: '0.7.0a4'
In [3]: flint.__FLINT_VERSION__
Out[3]: '3.1.0'
In [4]: flint.__FLINT_RELEASE__
Out[4]: 30100
No, it will completely break I think if you install This does complicate things. In principle there should be a way to have pip and meson-python build their own version of Flint and bundle it into the Python installation isolated from the rest of the system. This was discussed here but no conclusion was reached: Otherwise you would need some way to install a separate version of Flint and sort of activate it somehow when you want to use python-flint which can be done with environment variables but is messy. I think that at this point you are probably best to stick with python-flint 0.3.0 until the wheels are ready for aarch64. The newest version of python-flint that you can have is 0.4.4 but the changes from 0.3.0 to 0.4.4 are unlikely to be significant for you. A few bugs were fixed, especially so that it would work on Windows, but most other changes were just adding a lot of tests and adding binary wheels.
You have multiple installations of Python. When you run
This one I can't answer. I don't have any Linux aarch64 machine to test on and no way to test in CI. I assume that it works fine because there are no bug reports, just a request to add binary wheels (gh-105). |
Thank you for all your help! As you suggest, I will stick with python-flint 0.3.0 until the wheels are ready for aarch64. Is there any known or rumored timeline for this? The main use-case I have been using Flint for is for univariate polynomial multiplication with rational coefficients. I have two polynomials, p1 and p2, for which I keep terms up to O(x^5000), and then wish to find their product up to O(x^5000). Importantly, we require the exact rational values of these coefficients. Flint has been much faster than other packages such as SymPy, though I noticed in the most recent versions of Flint, that there are a few more options for potential speedups; namely, the
I was indeed playing around with Flint in a notebook. I imagine this is not an issue.
Would this lead to problems if the multiple installations of Python are distinct? Is it standard to keep the issue open until the aarch64 wheels are ready, or should the issue be marked as resolved? |
We're waiting for GitHub Actions to provide CI runners. They have said something vague like "maybe by the end of the year". Then if there are no problems with it adding the platform to the wheel-building matrix is not difficult.
The latest version of SymPy (1.13) will use python-flint internally for some things like this but only if you have Specifically in SymPy 1.13 a univariate Poly with coefficients in ZZ, QQ or GF(p) will actually have a Flint polynomial inside: In [1]: p = Poly(x**2 + 1)
In [2]: p
Out[2]: Poly(x**2 + 1, x, domain='ZZ')
In [3]: p.rep
Out[3]: DUP_Flint([1, 0, 1], ZZ)
In [4]: p.rep._rep
Out[4]: x^2 + 1
In [5]: type(p.rep._rep)
Out[5]: flint.types.fmpz_poly.fmpz_poly When python-flint 0.7.0 is released it will also have multivariate polynomials over the same domains and I expect that SymPy 1.14 will use those for multivariate Poly as well.
I haven't actually looked into how python-flint interacts with Flint's multithreading capabilities. We have this: In [6]: from flint import ctx
In [7]: ctx.threads
Out[7]: 1 I'm just not sure what that actually means in practice. As for mullow I'm not sure how much speedup you would reasonably get in your situation. You can use that already though because python-flint's |
We have a separate issue for that (gh-105). I have also opened a PR (gh-194) that adds better checking of build requirements to fix some of the other issues identified above. Hopefully in future someone attempting I would say that we can close this issue although feel free to open another about adding any particular functionality from Flint that you think would find useful. |
At least in current Flint this is how you use it: In [6]: from flint import *
In [7]: ctx.cap = 5
In [8]: x = fmpq_series([0, 1])
In [9]: x
Out[9]: x + O(x^5)
In [10]: x.exp()
Out[10]: 1 + x + 1/2*x^2 + 1/6*x^3 + 1/24*x^4 + O(x^5)
In [11]: x.exp() ** 2
Out[11]: 1 + 2*x + 2*x^2 + 4/3*x^3 + 2/3*x^4 + O(x^5) I tried setting the cap to 5000 to see what happens: In [17]: ctx.cap = 5000
In [18]: x = fmpq_series([0, 1])
In [19]: %time xexp = x.exp()
CPU times: user 38.6 ms, sys: 0 ns, total: 38.6 ms
Wall time: 37.7 ms
In [20]: %time xexp2 = 2*xexp
CPU times: user 53.3 ms, sys: 3.92 ms, total: 57.2 ms
Wall time: 56.9 ms
In [21]: %time prod = xexp * xexp2
CPU times: user 4.9 s, sys: 441 ms, total: 5.34 s
Wall time: 5.36 s
In [26]: xexp_poly = fmpq_poly(list(xexp))
In [27]: %time prod_poly = xexp_poly * (2* xexp_poly)
CPU times: user 3.71 s, sys: 313 ms, total: 4.02 s
Wall time: 4.14 s So it doesn't seem like mullow is much faster in this situation. I think that is because it is actually just computing the full product and discarding the terms. Using mullow is a lot faster if you have high degree polynomials but only want to keep a low degree part of the product. In your case you want to multiply two 5000 degree polynomials making a 10000 degree polynomial and then discard half of the terms. I expect that it is just faster to do this by using the full optimised |
So I got a small speedup ( In [18]: ctx.threads = 1
In [19]: %time r = xexp ** 2
CPU times: user 3.63 s, sys: 156 ms, total: 3.79 s
Wall time: 3.77 s
In [20]: ctx.threads = 4
In [21]: %time r = xexp ** 2
CPU times: user 4.87 s, sys: 262 ms, total: 5.14 s
Wall time: 2.98 s No point in going higher than 4 on this machine but I will certainly test on another machine at some point. |
Thank you for the advice! I implemented
Unfortunately, I do not see I achieved a slightly larger speedup setting the threads to 4 over 1, achieving a time of ~10 seconds. I'll test it with a higher thread count later -- I need to reinstall CYTools as I messed around with the packages too much. As a note which I will work on resolving: a collaborator who is also on an aarch64 machine was able to successfully install python-flint 0.6.0 despite also having CYTools. Part of the problem I was having may have been that CYTools runs on a Docker image, and I was running Jupyter notebooks through this Docker image while also using CYTools. Perhaps if I am in an environment outside of this Docker image and away from CYTools, I can run the updated version of python-flint. I will try this out and let you know! |
This is the C function that is called internally when you multiply two In [6]: fmpq_poly([1, 2]) * fmpq_poly([3, 4])
Out[6]: 8*x^2 + 10*x + 3 My suggestion is that at the C level mullow may actually just end up calling this same function anyway if you are not asking for a small number of terms.
Okay, and this explains why you have multiple Python installations: one is inside Docker. Having just revisited the error messages above I realise that it is not (necessarily) that you have an old version of Flint. Rather the error messages are consistent with simply not having Flint at all. If you do only have it inside a Docker image then that would make total sense. If that is the case then I would suggest to just build and install Flint 3.1. Then That being said it sounds like you have a complicated setup so it's hard for me to be sure of anything... |
I now have a fresh install of CYTools with python-flint 0.3.0 working on it again. Running the same tests, I find Regardless, even with python-flint 0.3.0, this is a wonderful time improvement over my other attempts! I plan to build and install Flint 3.1 as suggested and will send updates as they come. Hopefully this resolves the issues! Repeating a question from earlier: is there somewhere I should look to find the global attributes such as |
The documentation for python-flint is here but it is out of date and needs to be moved to a different domain: |
Updated CYTools to use The problem in CYTools with upgrading just by setting Thank you for helping us move to an updated version of Flint! |
Glad to hear it's worked out! By the way to follow up on one of your earlier questions I have pushed latest docs to a new location: |
Hello,
I hope this is the correct location to ask about such an issue. I have been working with
pip install --upgrade python-flint==0.3.0
without problem, and recently tried to install the latest version viapip install python-flint
after uninstalling the above version. When doing so, I run into the following error message:I apologize if this is the wrong place to ask such a question, or if this is a personal issue rather than an issue with the code. Thank you for the help!
The text was updated successfully, but these errors were encountered: