On Fri, Feb 2, 2024 at 9:41 AM Oscar Benjamin <[email protected]> wrote: > > Hi all, > > It is past time that a new release of SymPy is needed. Let's get SymPy > 1.13 out ASAP. > > I had been meaning to put out a bugfix release of SymPy 1.12.1 because > of a few things that have been fixed since SymPy 1.12 but it didn't > happen. In particular compatibility with Python 12's ast module for > parsing string expressions was fixed and a few other small things. > Also some changes were recently made for compatibility with NumPy 2.0 > which is probably going to be released in a few months but we should > get out a SymPy release first. > > There are of course also many other improvements since SymPy 1.12. You > can see the release notes here: > https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13 > > I've created a release issue here to track releasing 1.13: > https://github.com/sympy/sympy/issues/26169 > > Please say if there are any release blocker issues or other things > that should be resolved before the release. > > Here is one from me: > > After the 0.6.0 release of python-flint I would like to get this PR > merged to use Flint for polynomials and matrices over GF(p) as well as > ZZ and QQ: > https://github.com/sympy/sympy/pull/25940 > > A larger issue to be resolved is how exactly SymPy should use > python-flint. Currently with the SymPy master branch it is necessary > to set an environment variable SYMPY_GROUND_TYPES=flint to get SymPy > to use python-flint. That is not how it works with gmpy2 though, which > will just be picked up automatically when it is installed without the > need to set an environment variable. > > In principle the use of python-flint should not change the behaviour > of SymPy at all except that some particular things are made a lot > faster. Currently those things are: > > - Univariate polynomials over ZZ, QQ (and GF(p) if the PR above is > merged). This means various functions like `factor`, `gcd` etc are > faster. > - Algebraic extension fields like QQ.algebraic_field(sqrt(2)) since > their ANP type uses Flint's univariate polynomials as well now. > - The dense format of DomainMatrix when the domain is ZZ, QQ (or GF(p) > if the PR above is merged). > > These changes are very particular about what exactly is or is not made > faster but some particular operations are made much faster and for > others it makes no difference. In future Flint's multivariate > polynomials will be used and that will end up having a more noticeable > impact on the speed of higher-level operations for most end users. > > The question is whether to be conservative about making use of > python-flint by requiring an opt-in environment variable like this. > There are two possible downsides for a given user if SymPy starts > using python-flint automatically: > > 1. It is not yet that widely tested by many different people on > different computers etc so it is possible that there are unknown bugs. > 2 I expect that many things will change in python-flint over the next > few years. It is possible that a SymPy release of 1.13 now will not be > fully compatible with say a future release of python-flint in a few > years time. > > Note that python-flint is not as widely used or installed as SymPy by > a long way. I doubt that there are many people who just happen to have > python-flint and SymPy installed and would then be surprised that > SymPy started using python-flint. Probably most of the time the fact > that someone has installed both packages together is because they want > SymPy to use python-flint. > > I think that probably the right way to do this is just for SymPy to > use python-flint by default if it is installed but with an almost > exact version check like `python-flint == 0.6.x` because `0.6.0` is > the minimum version needed for the PR above but also the maximum > version that has been tested before release. It would be good to allow > the flexibility to have `0.6.1` though in case there is a small bugfix > release of python-flint. Over time if things seem more stable then we > could relax that version constraint. The environment variable could > still be used to override the version check but the default if no > environment variable is set should just be to use python-flint but > only the expected 0.6.x versions. > > Does anyone have any thoughts on how exactly to do this?
I think it should just be enabled by default. Almost no one will have flint installed, so only people who go out of their way to install it will get the benefits, so requiring an opt-in is just an extra step for those people. The only way this wouldn't be the case is if we add flint as a dependency in the conda package like we do for gmpy, but it sounds like it's a bit early to do that. Although I'm wondering about Sage. Does Sage always install both SymPy and python-flint? As for the verison checks, it depends on how likely you expect there to be breaking changes in python-flint. If that package is going to have a lot of breaking changes, it will make using it in SymPy a lot harder. Aaron Meurer > > -- > Oscar > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxTb9K-2uLsCCzfZGHK9HmFekM1LKHQJYVbys60aPr25pg%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BunHGnYDEhPoBZn9NWciunSuDp9%3DVKSV2ur-k99%3DFsJw%40mail.gmail.com.
