✅

Hi, I am the SymPy bot. 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
  • A bug preventing the use of the old assumptions under evaluate(False) was fixed. (#23693 by @oscarbenjamin)

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

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

Fixes #22428

See also the discussion about evaluation in the assumptions system here: https://github.com/sympy/sympy/pull/23488#discussion_r903204398

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

Avoid creating new expressions during assumptions queries. This makes the old assumptions slightly less powerful but at the same time faster and simpler and more robust. This also fixes a bug making it safe to query the old assumptions under `evaluate(False)`.

#### Other comments


#### 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
  * A bug preventing the use of the old assumptions under `evaluate(False)` was fixed.
<!-- 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
     [e0d6b5cf]       [24141c16]
-        95.0±2ms       62.6±0.8ms     0.66  integrate.TimeIntegrationRisch02.time_doit(10)
-        93.2±2ms       61.7±0.5ms     0.66  integrate.TimeIntegrationRisch02.time_doit_risch(10)

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

The change here exposed a bug in solveset. I've improved the checking of solutions to equations with radicals and fixed some tests.

Thanks @smichr. I've incorporated your suggestions with small changes.

I'm marking this as ready for review.

The general idea here about removing recursive evaluation in assumptions is good.

But can we really rely on assumptions functioning in evaluate=False? Do we know that the basic canonicalization that is disabled by evaluate=False would never be implicitly assumed in an assumption handler?

But can we really rely on assumptions functioning in evaluate=False? Do we know that the basic canonicalization that is disabled by evaluate=False would never be implicitly assumed in an assumption handler?

No, we don't know that but really that constraint should be respected by the assumptions system. Code in the assumptions system that does anything else should be changed (and there are many examples).

This is the one remaining release blocker.

Can anyone review it?

If not I'll remove the milestone.

This looks ok to me (though I am sure I could be missing something in the Complements and ConditionSet logic. But I don't see a reason to hold this up. (I just happened to notice this in a look at recently changed PRs so just finished relooking at it.)

Thanks!