>>> import sympy
>>> x=sympy.var('x')

Zero is sometimes wrongly reported as a solution.

>>> sympy.solve(-(1 + x)/(2 + x)**2 + 1/(2 + x), x)
[0]

There is a corresponding "TODO" in the source code, but it would be easy to
verify if 0 is an effective solution.
(# TODO: we might have introduced unwanted solutions when multiplied by x**-m)


Note that some calculus also lead to infinite recursion.

>>> sympy.solve(1/x,x)
[...]
<type 'exceptions.RuntimeError'>: maximum recursion depth exceeded


I've patched my own sympy installation ; if I manage to find some time,
I'll try to deal with all the git stuff to produce a proper sympy patch.

Original issue for #4793: http://code.google.com/p/sympy/issues/detail?id=1694 Original author: https://code.google.com/u/117997262464115802198/ Referenced issues: #4871, #5117, #5016, #5086, #5091, #5226, #5035, #4463, #4464, #5171, #4922, #5098 Original owner: https://code.google.com/u/117997262464115802198/

This introduces basic rewrite rules and strategies to SymPy.

It also uses these rewrite rules to refactor the MatrixExpressions module

TODO

1. ~~Rename as_factor_mul. Merge with as_coeff_mmul~~
2. ~~rewrite linear_factors (uses a lot of Expr functionality)~~ I've removed this all-together. The definition isn't consistent. I'll work on this in a future PR. Currently only work in other branches of mine uses this sympy.stats.mvnrv
3. MatMul/MatAdd don't simplify by default (maybe?) (I'm going to wait on this.)
4. ~~simplification in MatMul/MatAdd doesn't have to traverse entire tree~~

rr/rl.py         - some fundamental rules
rr/strat_pure.py - strategies that have nothing to do with SymPy
rr/traverse.py   - strategies that traverse a SymPy AST
rr/strat.py      - some conglomerate strategies that do depend on SymPy

matrices/expressions/mat(add/mul).py - Some rules written in normal python language and the use of strategies to combine those rules. Can we replace these by something higher level written in the SymPy language? If so what? These files provide examples of the sorts of rules we'll want to write. The rules are at the bottom matrices/expressions/blockmatrix.py -- I replaced block_collapse (a giant function) with rules. This is a good change but could have been done just as easily by adding methods to existing classes. This is a more aggressive example of using rules to program SymPy. It's rules-for-transformation rather than just rules-for-canonicalization.

This is my final pull request of GSOC code. I understand that the gsoc-2 pull request is still being reviewed (which makes this one look quite monstrous, with >80 commits..), but as suggested elsewhere I'm trying to submit all pull requests (i.e. this one) before the soft pencils down deadline. Also submitting this pull request is my pledge not to rebase the branch more often than absolutely necessary.

The commits in this pull request can be separated roughly into three categories (and in principle I could submit separate pull requests for each of these, although I'm not sure if this is helpful):

• new special functions (polylog, lerchphi, exponential integrals; with varying degree of support for integration)
• general improvements to integration (neater output, more clever heurstics)
• performance improvements

Over the next few days I will go through and label all the commits (according to a consistent scheme to be come up with...) in order to make reviewing easier (which will of course mean rebasing...)

Added function cauchy_principal_value in sympy/integrals/integrals.py to implement calculation of Cauchy's principal value

Took help (code) and reviews by @asmeurer in #14538

Note : I found this PR (#14538) quite helpful, and since there wasn't any on-going activity for quite some time, I decided to take it up and fix the issues and also add the reviews given by @asmeurer in the original PR.

Also, If required, I will add more tests and examples for the same.

Please review this PR and give me a feedback. Thanks

Release Notes

• integrals
  • added method principal_value to class Integral to calculate Cauchy's principal value along with tests.

Application of qapply(Rotation(alpha,beta,gamma)*JzKet(1,1)) [define the symbols alpha beta and gamma](And these are dummy) would ask for the inputs of alpha,beta,gamma.The parameters used in calling the function must be used to in the method and this is not happening so I had to ask for the input.Is there anyway that I could get it working without the use of asking for input.The issue is not completely solved because the same method has to be written for every spin state.

References to other Issues or PRs

Built upon #18436.

Brief description of what is fixed or changed

This PR adds a class for representing LTI systems in transfer function form.

Other comments

TODO:

• [x] adding TransferFunction class along with its functionality.

• [x] Rewrite unit-tests and make sure they pass.

• [x] Adding documentation.

Release Notes

• physics.control
  • Add TransferFunction, Series, Parallel, and Feedback class for physics.control submodule

Please see this: http://code.google.com/p/sympy/issues/detail?id=3548

Also, see this: https://groups.google.com/forum/?fromgroups=#!topic/sympy/xXyiOUWH0SU

According to the discussions on above links, this PR introduces solving quintics exactly (not numerically) when they are solvable.

There are a lot of constants involved. So, I created a new file and made a new class for quintics containing required constants. Also note that solving quintics exactly takes( for x5 + 15*x +12 =0 ) ~ 40 secs. The long time is attributed to solving five equations of the form x5 - R =0 somewhere in the middle of the code.

Also, I have used simplify a few times. It seems that the code became almost 3 times as fast with using simplify, than without it.

There is an extra flag; quintics. When set to true, the new roots_quintic method is called and if the quintic is solvable, the solution is returned. I am attaching a screenshot :

Here you can see the solution of x*_5 + 15_x +12 = 0.

I have not added any tests. @asmeurer Please look at the code. Let me know for changes required.

Here is a proof of concept of how I think the new assumptions should be done, as per https://code.google.com/p/sympy/issues/detail?id=3929. Take a read of the commit messages. The basic idea is that instead of writing handlers that look for expressions like Q.zero(x*y) and return new expressions that it knows are true like Q.zero(x) and Q.zero(y), the handler system returns a set of predicate statements, and everything is done using satisfiable(). This not only makes things cleaner, and gives us a single point of contact to make the assumptions faster (the dpll algorithm), it also allows computing things that are impossible to do under the current handler system. For instance

>>> from sympy.assumptions.newask import newask
>>> newask(Q.zero(x) | Q.zero(y), Q.zero(x*y))
True
>>> newask(Implies(Q.zero(x), Q.zero(x*y)))
True
>>> newask(Q.zero(x) | Q.zero(y), Q.nonzero(x*y))
False
>>> ask(Q.zero(x) | Q.zero(y), Q.zero(x*y))
>>> ask(Implies(Q.zero(x), Q.zero(x*y)))
>>> ask(Q.zero(x) | Q.zero(y), Q.nonzero(x*y))

It's impossible to write a handler that says "x is zero or y is zero, but we don't know which one".

I would like some feedback at this point. This code is completely proof of concept. The API is terrible (basically nonexistant). What I've got now is completely unscalable. It already is getting out of hand, and I've only got four assumptions, real, positive, zero, and nonzero.

I've completely ignored the existing ask() code, because I didn't want to spend a lot of time at this point trying to understand it (it's quite complicated), so I basically wrote the prototype from scratch. Even so, it's quite simple, and I think once you grok how the satisfiable bit works, it is easy to understand the rest.

So my biggest questions now are, do people like this idea? Do you foresee any major issues with it? Most importantly, what would be a good way to organize the new-style "handlers" (relevant fact extraction) so that it is scalable, extensible, and readable?

Update: newask has been changed to satask

This PR aims to rewrite a cleaner and robust univariate equation solver.

• [x] polynomial
• [x] rational
• [x] real trigonometric
• [x] write 4 tests to complete coverage
• [x] correct typo
• [x] correct this failure

Nonblocking todo

• [ ] functions solvable by LambertW
• [ ] functions that can be recast as polynomials with a change of variables this, for example; this can be factored out of solve where multiple generators are handled
• [ ] use something like this to handle the XFAILed test test_real_imag_splitting1, this will be handled in the set module.

Hi there! I'm currently writing a system of indexed n-dimensional arrays and valued tensors.

BUGS AND ISSUES:

• [ ] put more comments about the code.
• [ ] create TensorIndexType.from_data( ) / TensorIndexType.from_symmetry( ) methods.
• [x] missing tests for .applyfunc on TensExpr.
• [x] create .strip( )
• [x] test .strip( )
• [ ] repeat all of Pernici's tests on valued tensors as well (or maybe not really all of them).
• [ ] mark all autodrop points with comments.
• [x] check that MultiArray never replaces TensorSymmetry in all objects' args.
• [x] MultiArray shall never autodrop.
• [ ] test many NumericIndices on the same tensor.
• [x] create tests with non-diagonal metric.
• [ ] create tests for MultiArray of rank zero.
• [ ] correct args in TensMul, and everywhere else
• [ ] remove @XFAIL from core tests.
• [x] NumericContravariant and NumericCovariant: only int indices
• [ ] Decide if NumericContravariant and NumericCovariant are to be subclasses of Basic.
• [x] direct_sum in MultiArray
• [x] create tests for direct_sum
• [ ] direct sum of tensors
• [ ] tensor product of tensor indices (and method on tensors as well).
• [ ] check args in TensorIndexType and TensorIndex
• [ ] check args in valued TensorIndexType
• [ ] generator MultiArray.create( … ) for rank 0 ?
• [ ] extend MultiArray to higher rank?
• [ ] Why in TensorHead isn't comm passed to Basic's constructor?
• [ ] more control for wrong data in constructors.
• [ ] test type( … *args ) in NumericContravariant
• [ ] construct new data from self.args and check equality and hash compatibility with original data.
• [ ] find all TODO and solve the problems
• [ ] remove all TODO
• [ ] should MultiArray be renamed NDArray or something else?
• [ ] can we inspect numpy's code for their implementation of nDarrays, and import some features here?

References to other Issues or PRs

Closes #18769 Fixes #18768

Brief description of what is fixed or changed

Other comments

Release Notes

• core
  • Extensible add, mul and power functions are introduced to allow sympy objects to define what classes should be used for them in place of Add, Mul and Pow (e.g. matrices use MatAdd). This is an experimental approach aimed at enabling the behaviour of core routines (expand, collect, etc) to be customised by user-defined types (e.g. MatAdd rather than Add). This mechanism is still experimental, is not fully implemented across the core and might be changed or removed in a future release of sympy.

The following code snippet produces an error for me in python3.11 using sympy 1.11.1:

import sympy
x,y,C = sympy.symbols("x,y,C")
a = sympy.Poly(x**4/(C**2 + 3*C + 2)*y, y, domain='ZZ(x,C)')
b = sympy.Poly((12*C**12*x**8 + 60*C**12*x**7 + 72*C**12*x**6 + 24*C**12*x**5 + 108*C**11*x**8 + 540*C**11*x**7 + 660*C**11*x**6 + 240*C**11*x**5 + 12*C**11*x**4 + 414*C**10*x**8 + 2076*C**10*x**7 + 2580*C**10*x**6 + 1008*C**10*x**5 + 84*C**10*x**4 + 876*C**9*x**8 + 4608*C**9*x**7 + 5824*C**9*x**6 + 2400*C**9*x**5 + 240*C**9*x**4 + 1194*C**8*x**8 + 6876*C**8*x**7 + 8820*C**8*x**6 + 3816*C**8*x**5 + 408*C**8*x**4 + 1203*C**7*x**8 + 7596*C**7*x**7 + 9912*C**7*x**6 + 4560*C**7*x**5 + 540*C**7*x**4 + 897*C**6*x**8 + 6348*C**6*x**7 + 8474*C**6*x**6 + 4176*C**6*x**5 + 564*C**6*x**4 + 438*C**5*x**8 + 3816*C**5*x**7 + 5236*C**5*x**6 + 2784*C**5*x**5 + 408*C**5*x**4 + 96*C**4*x**8 + 1488*C**4*x**7 + 2170*C**4*x**6 + 1344*C**4*x**5 + 240*C**4*x**4 + 288*C**3*x**7 + 484*C**3*x**6 + 384*C**3*x**5 + 96*C**3*x**4)/(72*C**13 + 864*C**12 + 4680*C**11 + 15408*C**10 + 35280*C**9 + 61056*C**8 + 83952*C**7 + 93600*C**6 + 84744*C**5 + 61920*C**4 + 35784*C**3 + 15408*C**2 + 4320*C + 576)*y**2 + (4*C**6*x**4 + 12*C**6*x**3 + 4*C**6*x**2 + 20*C**5*x**4 + 60*C**5*x**3 + 20*C**5*x**2 + 37*C**4*x**4 + 108*C**4*x**3 + 36*C**4*x**2 + 36*C**3*x**4 + 108*C**3*x**3 + 36*C**3*x**2 + 32*C**2*x**4 + 96*C**2*x**3 + 32*C**2*x**2 + 16*C*x**4 + 48*C*x**3 + 16*C*x**2)/(12*C**7 + 84*C**6 + 240*C**5 + 384*C**4 + 420*C**3 + 348*C**2 + 192*C + 48)*y + 1, y, domain='ZZ(x,C)')

a * b

The traceback is:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/polytools.py", line 72, in wrapper
    return func(f, g)
           ^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/polytools.py", line 4183, in __mul__
    return f.mul(g)
           ^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/polytools.py", line 1512, in mul
    result = F.mul(G)
             ^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/polyclasses.py", line 457, in mul
    return per(dmp_mul(F, G, lev, dom))
               ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/densearith.py", line 807, in dmp_mul
    return dup_mul(f, g, K)
           ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/densearith.py", line 767, in dup_mul
    coeff += f[j]*g[i - j]
             ~~~~^~~~~~~~~
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/fields.py", line 497, in __mul__
    return f.new(f.numer*g.numer, f.denom*g.denom)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/fields.py", line 301, in new
    return f.raw_new(*numer.cancel(denom))
                      ^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/rings.py", line 2223, in cancel
    _, p, q = f.cofactors(g)
              ^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/rings.py", line 2139, in cofactors
    h, cff, cfg = f._gcd(g)
                  ^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/rings.py", line 2172, in _gcd
    return f._gcd_ZZ(g)
           ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/rings.py", line 2177, in _gcd_ZZ
    return heugcd(f, g)
           ^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/heuristicgcd.py", line 80, in heugcd
    h, cff, cfg = heugcd(ff, gg)
                  ^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/sympy/polys/heuristicgcd.py", line 118, in heugcd
    raise HeuristicGCDFailed('no luck')
sympy.polys.polyerrors.HeuristicGCDFailed: no luck

This refers to bullet point 1.1, replacement of types, in documentation for sympy.core.basic.replace().

Situation

When replacing oldtype by newtype in an expression expr, expr.replace(oldtype, newtype) may call the constructor for oldtype and create further oldtype objects. Since oldtype is to be replaced by newtype this objects will then immediately be replaced by newtype objects, so this calls are superfluous at least. Moreover they are unexpected and may have unwanted performance or other side effects.

Example

from sympy import Expr, Add, symbols
class MathObj(Expr): # create a new mathematical object in SymPy from Expr, just for demo
    def __new__(cls, a1, a2):
        obj = Expr.__new__(cls, a1, a2) # sets up self.func, self.args
        print(f"__new__(MathObj, {a1}, {a2})") # show that __new__ is called
        return obj
# create some term using MathObj
n, m = symbols("n m")
p = MathObj(n, MathObj(m,m)) + MathObj(MathObj(n,n), m) #prints 4 times __new__(MathObj,..)
print("doing p.replace(MathObj, Add):")

q = p.replace(MathObj, Add) # calls and prints 2 times __new__(MathObj,...) !!

print(q) # prints 3*m + 3*n

Analysis This behaviour occurs if oldtype is nested within expr (as in the example above). In this case the statement rv = rv.func(*newargs) in function walk() in sympy.core.basic.replace() invokes the oldtype constructor. If rv.func == oldtype it should invoke newtype(*newargs) instead. However as replace() has various usages that are all handled by this code I'm unable to verify this.

References to other Issues or PRs

Brief description of what is fixed or changed

Topological sort used None as a default argument on the key field as a way to set a default like this lambda value: value. This can be achieved in a simpler way, by simply passing the default lambda as a default argument instead of none-checking.

Other comments

Release Notes

• utilities
  • iterables: topological sort takes natural value as default parameter, instead of getting it as None

References to other Issues or PRs

Fixes #8634 Closes #22712

Brief description of what is fixed or changed

Returns output dependent on 'n' (hence varies when n is odd/even) instead of -oo.

P.S. - This is a reproduction of #22712 which has already been reviewed to be correct by a couple of maintainers of the series module. It was contributed before the mailmap was introduced hence I am repeating it as suggested here .

On master -

>>> n = Symbol('n', integer=True, positive=True)  # could be 2 or 3...
>>> limit(x**n, x, -oo)
-oo

On branch -

>>> limit(x**n, x, -oo)
oo*sign((-1)**n)

Other comments

Release Notes

• series
  • Fixes limit at negative infinity considering odd or even power.

References to other Issues or PRs

Fixes #24456

Brief description of what is fixed or changed

Changed the bug-fixed example in the template now it is more specific and helpful.

Other comments

Release Notes

NO ENTRY

From #24443:

The example for what to write when a bug is fixed could be more helpful with a specific example. The template would need to be edited, perhaps like this:

* Fixed a bug with log of integers. Formerly, `log(-x)` incorrectly gave `-log(x)`.