✅

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:

• matrices
  • Better support for computing adjoint, re, and im for Identity, OneMatrix, and ZeroMatrix. (#23724 by @oscargus)

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

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

A small step towards #23609 for matrices.

#### Brief description of what is fixed or changed


#### Other comments

I should add some tests.

#### 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 -->
* matrices
   * Better support for computing `adjoint`, `re`, and `im` for `Identity`, `OneMatrix`, and `ZeroMatrix`.
<!-- 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
     [77f1d79c]       [edf24253]
     <sympy-1.10.1^0>                 
+      99.3±0.8ms        180±0.5ms     1.81  sum.TimeSum.time_doit

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

Interesting that the matrices already use _eval_as_real_imag, although it looks like the current implementation in master is wrong (see the XXX comment in common.py).

We might want to figure out for #23609 in general how we want to handle deprecation. It's hard to just switch from method to _eval_method because user subclasses that redefine method will break, because it will use that version instead of the base class version that calls _eval_method.

So we need to either deprecate redefining method, or else somehow make it so it still works. But I'm not sure if that's possible. I'm not even sure if we can issue a warning for redefining method, unless we put some logic in the metaclass.

Interesting that the matrices already use _eval_as_real_imag, although it looks like the current implementation in master is wrong (see the XXX comment in common.py).

Indeed! I was a bit confused about the status at first... Yes, I noted the comment but though that I take the simple way out for now and do not touch anything else.

We might want to figure out for #23609 in general how we want to handle deprecation. It's hard to just switch from method to _eval_method because user subclasses that redefine method will break, because it will use that version instead of the base class version that calls _eval_method.

I guess that ideally, it shouldn't break anything but I can see many cases where it indeed may do it.

This is really a case where it would be nice to have code coverage... Right now, I modify things and hope that they are tested so that I do not break anything...

I'd be a bit tempted to get this in 1.11 as well... But feel free to remove.

The benefit is that in the added test, in current master e.g. re(X) becomes

while here it becomes

So basically more things involving re, im and adjoint evaluates to something more sensible.

Looks good.