✅

Hi, I am the SymPy bot (v162). 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:

• core
  • nan is returned for any power (with exponent not 0 or 1) with infinite real and imaginary portions, e.g. 1/(oo + I*oo)->nan (#22516 by @smichr)

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

<!-- 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
<!-- 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


#### Other comments

This is in response to an inline comment in `test_add_flatten` which noted that `1/(oo + I*oo) -> 0*(oo - I*oo)`.

#### 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 -->
* core
    * nan is returned for any power (with exponent not 0 or 1) with infinite real and imaginary portions, e.g. 1/(oo + I*oo)->nan
<!-- END RELEASE NOTES -->

Update

The release notes on the wiki have been updated.

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
     [907895ac]       [fd93490a]
-         4.76±0s          299±2ms     0.06  polygon.PolygonArbitraryPoint.time_bench01

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

Shouldn't 1/(oo+I*oo) be just 0?
As oo+I*oo is just a special case of zoo, indicating both re and im are infinity.

Shouldn't 1/(oo+I*oo) be just 0?

1/(1 + I) is (1 - I)/((1 + I)*(1 - I)) -> (1 - I)/2 so I am returning nan by analogy since the denominator would be undefined.

Checking with semi-finite versions, the issue also arises (but is not addressed in this PR, but could be):

>>> 1/(oo+3*I)
0*(oo - 3*I)
>>> (oo+3*I)*(oo-3*I)
(oo - 3*I)*(oo + 3*I)
>>> expand(_)
nan

>>> 1/(3+I*oo)
0*(3 - oo*I)
>>> (3+oo*I)*(3-oo*I)
(3 - oo*I)*(3 + oo*I)
>>> expand(_)
nan

Any objections?

nan is always safe (like None in tests) but I think that more precise results could be given. oo + I*oo can be regarded as a refinement of zoo: its absolute value is infinite but its argument can be thought of being between 0 and pi/2. When it is raised to a power greater than 4 (or less than -4), all information of its argument will be lost as 4*pi/2 = 2*pi, so I think that it could be treated as zoo when raised to a power (even if the exponent is between -4 and 4). So, for positive exponents, we could have zoo instead of nan:

In [23]: zoo*2                                                                  
Out[23]: zoo

In [24]: zoo*(S(1)/2)                                                           
Out[24]: zoo

and for negative exponents , 1/zoo which is 0. Only (oo + I*oo)**0 cannot be determined and could be nan.

@eagleoflqj , @jksuom -- does this look right now? And is this right to all exponents of +/-oo to give results similar to +/-2 (finite version)?

This looks good to me.

Thanks @jksuom