Add test case for subs

[ayushbisht2001]

References to other Issues or PRs

refer: #16318

Brief description of what is fixed or changed

Other comments

Release Notes

NO ENTRY

[sympy-bot]

✅

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.

• No release notes entry will be added for this pull request.

Click here to see the pull request description that was parsed.

<!-- 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. -->
refer: #16318

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


#### 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 -->
NO ENTRY
<!-- END RELEASE NOTES -->

[oscarbenjamin]

Can you use two blank lines between test functions (also fix this for the function above)?

[oscarbenjamin]

What exactly is this improving the coverage of?

[ayushbisht2001]

@oscarbenjamin , I found simultaneous a good option for evaluating some of the undefined expression and there is not any specific test case which exactly shows its purpose.

[eagleoflqj]

I'm not sure why the first result should be 0. That is, why 0/y == 0 without knowing y.is_zero?

[github-actions]

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]       [a6e74d2b]
     <sympy-1.10.1^0>                 
+         112±2ms          198±6ms     1.77  sum.TimeSum.time_doit

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

[ThePauliPrinciple]

I'm not sure why the first result should be 0. That is, why 0/y == 0 without knowing y.is_zero?

I came across this issue too at some point. Clearly, strictly speaking this can't be resolved of course. However, not doing this seems to just blow up the complexity of many algorithms.

Currently this already happens during canonicalisation in class Mul I believe.

>>> import sympy
>>> import sympy.abc
>>> sympy.S.Zero/sympy.abc.y is sympy.S.Zero 
True

Changing it breaks a lot of things and it is not clear how to resolve this. Perhaps Expr needs to store all discontinuities, or perhaps a Zero class can be created which stores this informat (in that case it can't be a singleton anymore since every Zero will potentially be different.

But as far as I understand, this is currently the expected behaviour in SymPy

[oscarbenjamin]

I'm not sure why the first result should be 0. That is, why 0/y == 0 without knowing y.is_zero?

See #17224