✅

Hi, I am the SymPy bot (v167). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

Your release notes are in good order.

Here is what the release notes will look like:

• concrete
  • A bug leading to incorrect results when evaluating some infinite summations was fixed. Previously an incorrect result might be found in some cases if the summation symbol was defined with the integer=True assumption set. (#23507 by @KuldeepBorkar)

This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.11.

A dummy symbol with no assumptions set for get_residue_factor

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
Fixes #23491 
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->


#### Brief description of what is fixed or changed
In _sympy/concrete/summations.py_ **get_residue_factor(**),  'i' was used with assumption set **integer = True** but the problem is that **cot(S.Pi * i) gives zoo(complex infinity)** therefore we need to use a dummy symbol with no assumption set to get_residue_factor to calculate the residue around the pole rather than evaluate the expression at the pole.

#### Other comments
- [x] Opened on a seperate branch
- [x] Has unit tests
- [x] Follows Documentation Guidelines
- [x] Has Release Notes

#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
* concrete
   * A bug leading to incorrect results when evaluating some infinite summations was fixed. Previously an incorrect result might be found in some cases if the summation symbol was defined with the `integer=True` assumption set.
<!-- END RELEASE NOTES -->

Update

The release notes on the wiki have been updated.

I will add a test case once all the checks are successful,
I am actually not able to decide with every PR that I should add Release Notes or not could someone please help me with that?
Whenever I make some changes related to the documentation I use NO ENTRY but with changes other than documentation I am confused ; )

The release note could be

* concrete
  * A bug leading to incorrect results when evaluating some infinite summations
    was fixed. Previously an incorrect result might be found in some cases if
    the summation symbol was defined with the `integer=True` assumption set.

Thank you @oscarbenjamin : )

It says Python version 3.8 or above is required for SymPy when I run bin/test_optional_dependencies.py
locally but SymPy supports Python 3.7 I think, (optional-dependencies check is failing for me the first time)

I see in SymPy 1.11 dev documentation it is mentioned SymPy officially supports Python 3.8, 3.9, 3.10, and PyPy that means it no longer supports 3.7 now.

The next release of sympy will not support 3.7 so "support" is already dropped on master. Probably you can just edit that line in the script though so that it still runs though. It isn't actually necessary to run that script though: if you have the dependencies installed then the ordinary test runner will run the same tests.

The failures in the optional dependencies are only seen under Python 3.10 and 3.11 though so to reproduce them you need to install Python 3.10 or Python 3.11b1 (and also many of the optional dependencies).

More importantly those failures are unrelated to this PR. Those jobs fail on the master branch which is why they are not required to pass for the PR to be merged.

Benchmark results from GitHub Actions

Lower numbers are good, higher numbers are bad. A ratio less than 1
means a speed up and greater than 1 means a slowdown. Green lines
beginning with + are slowdowns (the PR is slower then master or
master is slower than the previous release). Red lines beginning
with - are speedups.

Significantly changed benchmark results (PR vs master)

Significantly changed benchmark results (master vs previous release)

       before           after         ratio
     [77f1d79c]       [b418faaa]
     <sympy-1.10.1^0>                 
+      97.5±0.3ms        181±0.8ms     1.86  sum.TimeSum.time_doit

Full benchmark results can be found as artifacts in GitHub Actions
(click on checks at the top of the PR).

You may add test case now. The failing job doesn't matter.

Thank you @oscarbenjamin for your help (I always thought release notes should be something like one liner by looking at the examples mentioned while writing comment for a PR, also now I think writing Release Notes is a good practice now instead of simply writing NO ENTRY if change is something other than documentation)

@eagleoflqj I have added the test case now and updated Release Notes : )