SymPy 1.13.0rc1 released

[Oscar Benjamin]

Hi all,

I have just pushed SymPy 1.13.0rc1 to PyPI. This is a prerelease that
is being made available for early testing.

You can install this with:

pip install sympy==1.13.0rc1

Or alternatively:

pip install --upgrade --pre sympy

The release files can also be downloaded from GitHub:

https://github.com/sympy/sympy/releases/tag/1.13.0rc1

I expect that a full release of 1.13.0 will be made fairly soon and I
don't anticipate that there would be significant changes between rc1
and final release.

There are many changes since the previous release 1.12 which was just
over a year ago. you can find the release notes here although they
still need cleaning up:

https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13

One particular highlight of this release is that it can use
python-flint to accelerate some polynomial and other operations. It
would be great if people could test this out by installing
python-flint as well:

pip install python-flint==0.6

You can set the environment variable SYMPY_GROUND_TYPES to any of
python, gmpy2 or flint to control which backend is used. The most
easily noticeable difference python-flint makes for now is speeding up
operations with univariate polynomials:

$ SYMPY_GROUND_TYPES=python isympy
...
IPython console for SymPy 1.13.0rc1 (Python 3.12.0-64-bit) (ground
types: python)
...
In [1]: p = Poly(x + 1)

In [2]: %time factor_list(p ** 100)
CPU times: user 117 ms, sys: 183 µs, total: 117 ms
Wall time: 115 ms
Out[2]: (1, [(Poly(x + 1, x, domain='ZZ'), 100)])

$ SYMPY_GROUND_TYPES=flint isympy
...
IPython console for SymPy 1.13.0rc1 (Python 3.12.0-64-bit) (ground
types: flint)
...
In [1]: p = Poly(x + 1)

In [2]: %time factor_list(p ** 100)
CPU times: user 4.05 ms, sys: 16 µs, total: 4.07 ms
Wall time: 4.01 ms
Out[2]: (1, [(Poly(x + 1, x, domain='ZZ'), 100)])

That particular example shows a 30x speedup. Future releases of SymPy
will use flint for more operations so this is still in development but
it would be great for people to test this because although I have
tested SymPy with python-flint a lot I am not sure how many other
people have.

As always please report any problems with the release either here or
on Github. There are so many changes in this release that it is
basically guaranteed that there will be some issues discovered
afterwards but it would be great if we could pick up on some of them
before the final release rather than after.

## Authors

The following people contributed at least one patch to this release (names are
given in alphabetical order by last name). A total of 146 people
contributed to this release. People with a * by their names contributed a
patch for the first time for this release; 100 people contributed
for the first time for this release.

Thanks to everyone who contributed to this release!

- Daan Koning (he/him)*
- Anton Akhmerov
- Han Wei Ang*
- anutosh491
- Isidora Araya*
- atharvParlikar*
- Oscar Benjamin
- Evandro Bernardes
- Anurag Bhat
- Francesco Bonazzi
- Augusto Borges*
- João Bravo*
- Sam Brockie
- Pontus von Brömssen
- Steven Burns*
- Liwei Cai*
- Corey Cerovsek*
- HeeJae Chang*
- Abhishek Chaudhary*
- Abhinav Cillanki*
- codecruisader*
- Costor
- Björn Dahlgren
- Saikat Das*
- Ethan DeGuire*
- Theodore Dias*
- dodo*
- fazledyn-or*
- Emile Fourcini*
- Mark van Gelder*
- Riccardo Di Girolamo*
- Pascal Gitz*
- Aaron Gokaslan
- Kishore Gopalakrishnan
- Michael Greminger
- Oscar Gustafsson
- Nick Harder*
- Zac Hatfield-Dodds*
- Le Cong Minh Hieu*
- Warren Jacinto*
- Jerry James
- Hwayeon Kang*
- Samith Karunathilake*
- Harsh Kasat*
- Johannes Kasimir*
- Kaustubh*
- Steve Kieffer
- Evelyn King
- Matthias Köppe
- K. Kraus*
- Abhishek kumar*
- Abhishek Kumar*
- Shishir Kushwaha*
- S.Y. Lee
- Raphael Lehner*
- Matthias Liesenfeld*
- Qijia Liu
- Sam Lubelsky
- Fabio Luporini*
- Megan Ly
- Nikhil Maan
- Colin B. Macdonald
- Oriel Malihi*
- Mohak Malviya*
- Martin Manns*
- Tirthankar Mazumder
- Ehren Metcalfe
- Aaron Meurer
- mohammedouahman*
- Lukas Molleman*
- John Möller*
- Suman mondal*
- Jason Moore
- Harry Mountain*
- Arnab Nandi*
- Harrison Oates*
- omahs*
- Victory Omole*
- Julien Palard
- Bobby Palmer*
- Ishan Pandhare
- Jay Patankar*
- Prey Patel*
- Abhishek Patidar
- Idan Pazi*
- Ivan Petukhov*
- philwillnyc*
- George Pittock*
- platypus*
- Advait Pote
- James A. Preiss*
- Dean Price*
- Psycho-Pirate
- Sophia Pustova*
- Baiyuan Qiu*
- Ravindu-Hirimuthugoda*
- Juha Remes
- Mikhail Remnev*
- Tilo Reneau-Cardoso*
- Matthias Rettl*
- Mohamed Rezk*
- Konstantinos Riganas*
- Sam Ritchie*
- Richard Rodenbusch*
- Pedro Rosa*
- Alberto Jiménez Ruiz*
- Bhavik Sachdev*
- Taylan Sahin*
- Saicharan
- Pablo Galindo Salgado
- Richard Samuel*
- Davide Sandonà
- Raj Sapale
- Gilles Schintgen
- Nico Schlömer
- Hanspeter Schmid
- Alexis Schotte*
- Vladimir Sereda*
- Ankit Kumar Singh*
- Sachin Singh*
- Maciej Skórski*
- Chris Smith
- Henrique Soares*
- Vivek Soni*
- Timo Stienstra
- Grace Su*
- Kalevi Suominen
- Daiki Takahashi
- Diane Tchuindjo
- Gerald Teschl*
- Seb Tiburzio*
- Tommaso Vaccari*
- Geetika Vadali*
- Viraj Vekaria*
- Laurence Warne*
- Daniel Weindl*
- James Whitehead*
- Lorenz Winkler*
- Congxu Yang*
- 袁野 (Yuan Ye)*
- Lauren Yim*
- Zedmat*
- Shuai Zhou*
- Zhenxu Zhu*
- Alexander Zhura*
- zzc*

The SHA-256 hashes for the release are:

37392a943e14db2886543141c2121330887b6f834604a740a476f4b516315d11
sympy-1.13.0rc1.tar.gz
f6fce4b6b1ef4d89631fe81380f4e562e86615d2aef0bc3a17c4f1d0e3cd5dab
sympy-1.13.0rc1-py3-none-any.whl
b3b729284e791f4af8d792c67d7dbf30289563ff2acf3d6650c7eac7284e7f6d
sympy-docs-html-1.13.0rc1.zip
14436f97e203918ca9655491e79b412b3452e46e3fefa61c5f3d544c874c5788
sympy-docs-pdf-1.13.0rc1.pdf

--
Oscar

[Aaron Meurer]

Another important change in this release is that Rational (and
Integer) and Float objects no longer compare equal to one another with
==.

Previously:

>>> Integer(1) == Float(1.0)
True
>>> Rational(1, 2) == Float(0.5)
True

Now:

>>> Integer(1) == Float(1.0)
False
>>> Rational(1, 2) == Float(0.5)
False

This was previously applied inconsistently. For example, it always
worked this way inside of expressions

>>> x**2 == x**2.0
False

The motivation for this change is that == means structural, not
mathematical equality in SymPy, and rational and floating-point
numbers have different properties that make it inappropriate to
consider them to be equivalent. It also fixes a long standing issue
where Floats and Rationals would compare equal but not hash to the
same values.

This is a change that I expect could affect upstream projects, so if
you depend on SymPy I would suggest trying 1.13rc1 out and letting us
know if it affects you in a serious way.

Aaron Meurer

> --
> 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 sympy+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRUsh8CDHkJDc3dsYj4V_FkxWxa9MQpLSzw497bVni_9Q%40mail.gmail.com.

[Oscar Benjamin]

Hi all,

Some issues were reported with the SymPy 1.13.0rc1 release candidate.
Since then I pushed 1.13.0rc2 and 1.13.0rc3 and I'm about to push
1.13.0rc4. Thanks to everyone who tested the release candidate and
reported any problems.

I think this is a list of issues and PRs that have been included (or
will be in rc4):

https://github.com/sympy/sympy/issues/26731
https://github.com/sympy/sympy/issues/26688
https://github.com/sympy/sympy/issues/26690
https://github.com/sympy/sympy/pull/26627
https://github.com/sympy/sympy/issues/26692

There is one outstanding thing that I would like to resolve before the
final release which is the handling of the python-flint version.

Currently the situation with rc3 is that if you install python-flint
0.6.0 or hypothetically in future 0.6.1, 0.6.2, etc then when you
import sympy it will automatically use python-flint. If you have a
newer version of python-flint like 0.7.0 (which does not exist yet) or
an older version like 0.5.0 then it will print a warning and default
to not using python-flint (falling back on gmpy2 or just on using
Python types).

This warning looks like:

>>> import sympy
~/sympy/sympy/external/gmpy.py:126: UserWarning: python-flint 0.5.0
is installed but only version 0.6.* will be used by default. Falling
back to other ground types. Use SYMPY_GROUND_TYPES=flint to force the
use of python-flint.
warn(f"python-flint {_flint_version} is installed but only version "

The reason for not using python-flint 0.5.0 is that SymPy 1.13 uses
some features that were added in 0.6.0. The reason for not using
python-flint 0.7.0 is that hypothetically future releases of
python-flint might make significant changes making them not as fully
compatible with SymPy 1.13. This is only a hypothetical though and
there are not any plans for python-flint to break in a backwards
compatible way.

There are two questions here:

1. Should SymPy 1.13 just use newer versions of python-flint anyway?
2. If not, should SymPy warn about newer versions of python-flint?

I think that the answer to the warning question is that no there
should be no warning. These warnings end up being annoying for
downstream people who don't really care. That might mean that in
future some people are surprised by the fact that they have
python-flint installed but SymPy does not use it. I think that is
better than annoying other people with the warning.

For the question about using newer versions of python-flint I think
that at least SymPy 1.13 should be able to use a few future versions
of python-flint but I am not sure what is a reasonable future range of
versions. Possibly SymPy could use any python-flint >= 0.6.0, < 1.0
meaning that python-flint should not break any compatibility for SymPy
until it reaches version 1.0. We would need something somewhere to
test new versions of python-flint against potentially old versions of
SymPy though. I could add something in python-flint's CI to make sure
that it tests all changes against SymPy 1.13.

I think my preference is:

1. Use python-flint >= 0.6.0, < 1.0 automatically.
2. Don't use python-flint < 0.5.0 or >= 1.0 and don't give any warning about it.
3. Unless the SYMPY_GROUND_TYPES=flint variable is set in which case
use python-flint regardless of the version.
4. Keep future versions of python-flint compatible with SymPy 1.13
until python-flint 1.0.
5. Once SymPy 1.13 is released add a job in python-flint CI to test
against SymPy 1.13.

Does anyone have any views on this?

As far as I know this is the only outstanding item before final release.

--
Oscar

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BPQcwkJaGHXSMtxTwPGzQMzVPYdv4QVt7cPiqEDeQJpg%40mail.gmail.com.

[Aaron Meurer]

On Mon, Jul 1, 2024 at 4:38 AM Oscar Benjamin
<oscar.j....@gmail.com> wrote:
>
> Hi all,
>

I guess the most ideal would be if we could synchronize with the
upstream and have them promise that any release with a breaking change
would bump, say, the major version number. That we we could pin <1.0
and be sure that will be the right thing.

Also presumably if an issue does arise we can release a patch release
that adds a pin, so maybe it isn't a huge deal as long as we are able
to stay on top of it.

Aaron Meurer

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRSakG0A8%2BneCx3NRofBiQWkm8NoVo9z%2BFBnKnTg_OSgw%40mail.gmail.com.

[Oscar Benjamin]

On Mon, 1 Jul 2024 at 18:04, Aaron Meurer <asme...@gmail.com> wrote:
>
> On Mon, Jul 1, 2024 at 4:38 AM Oscar Benjamin
> <oscar.j....@gmail.com> wrote:
> >
> > I think my preference is:
> >
> > 1. Use python-flint >= 0.6.0, < 1.0 automatically.
> > 2. Don't use python-flint < 0.5.0 or >= 1.0 and don't give any warning about it.
> > 3. Unless the SYMPY_GROUND_TYPES=flint variable is set in which case
> > use python-flint regardless of the version.
> > 4. Keep future versions of python-flint compatible with SymPy 1.13
> > until python-flint 1.0.
> > 5. Once SymPy 1.13 is released add a job in python-flint CI to test
> > against SymPy 1.13.
> >
> > Does anyone have any views on this?
>
> I guess the most ideal would be if we could synchronize with the
> upstream and have them promise that any release with a breaking change
> would bump, say, the major version number. That we we could pin <1.0
> and be sure that will be the right thing.
>
> Also presumably if an issue does arise we can release a patch release
> that adds a pin, so maybe it isn't a huge deal as long as we are able
> to stay on top of it.

It can be hard to say sometimes what exactly is a "breaking change" vs
a bug fix. Ultimately if sympy depends on some behaviour of
python-flint then we won't know if a change causes problems without at
least running the test suite somewhere. It is unreasonable though for
python-flint to promise that all future releases will be fully tested
against all future releases of sympy in perpetuity.

The way that numpy and scipy do it is that they guarantee some range
so scipy is compatible with numpy 2.n to 2.n+2 which I think can also
work here.

If sympy uses python-flint 0.n to say 0.n+3 then python-flint can test
older versions of sympy for as long as they are "supported" and sympy
can just not use newer versions. Then we can say that sympy now
accepts 0.6.0-0.9.0 and python-flint can test against sympy 1.13 until
version 0.10.0.

I don't want to go back and make point releases for old sympy versions
for this kind of thing if possible. There are all kinds of other
things like new numpy versions, new Python versions etc that break old
releases of sympy. Backporting fixes for all of those opens a whole
bunch of questions about how long "support" is supposed to last for
old releases. Maybe that is where SPEC 0 comes in but SPEC 0 is time
based and neither sympy nor python-flint have regular release
schedules.

--
Oscar

[Oscar Benjamin]

On Tue, 2 Jul 2024 at 12:09, Oscar Benjamin <oscar.j....@gmail.com> wrote:
>
> If sympy uses python-flint 0.n to say 0.n+3 then python-flint can test
> older versions of sympy for as long as they are "supported" and sympy
> can just not use newer versions. Then we can say that sympy now
> accepts 0.6.0-0.9.0 and python-flint can test against sympy 1.13 until
> version 0.10.0.

This is what I went with in https://github.com/sympy/sympy/pull/26759

I've just pushed sympy 1.13.0rc4 and as far as I know all outstanding
issues are resolved. Unless we hear anything back from rc4 the final
1.13.0 release can be soon.

Oscar

[Aaron Meurer]

On Tue, Jul 2, 2024 at 5:09 AM Oscar Benjamin

How well can you isolate the parts of the SymPy test suite that
exercise flint. If it's straightforward to do that and those tests run
quickly, then you could easily have a job that runs them for SymPy
(latest release - 1, latest release, master) on the python-flint CI.

Aaron Meurer

>
> The way that numpy and scipy do it is that they guarantee some range
> so scipy is compatible with numpy 2.n to 2.n+2 which I think can also
> work here.
>
> If sympy uses python-flint 0.n to say 0.n+3 then python-flint can test
> older versions of sympy for as long as they are "supported" and sympy
> can just not use newer versions. Then we can say that sympy now
> accepts 0.6.0-0.9.0 and python-flint can test against sympy 1.13 until
> version 0.10.0.
>
> I don't want to go back and make point releases for old sympy versions
> for this kind of thing if possible. There are all kinds of other
> things like new numpy versions, new Python versions etc that break old
> releases of sympy. Backporting fixes for all of those opens a whole
> bunch of questions about how long "support" is supposed to last for
> old releases. Maybe that is where SPEC 0 comes in but SPEC 0 is time
> based and neither sympy nor python-flint have regular release
> schedules.
>
> --
> 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 sympy+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTRyUfZWpCPqKJ6ARW25Q5dXZ0qST8mQKE0ObUiVYL0Nw%40mail.gmail.com.

[Oscar Benjamin]

I was imagining doing that but just running the whole sympy test
suite. It takes about 15 minutes to run the whole not slow test suite
with pytest's parallel tests in Github Actions like:

import sympy; sympy.test(parallel=True)

It recently became worth using parallel tests in Github because the
number of cores was increased from 2 to 4 in the standard runners
which is why I removed the splits from CI.

For the python-flint CI it takes about 25 minutes just to build the
Windows wheels before the Windows tests can even begin so you would
hardly notice a job running the sympy test suite.

--
Oscar