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

References to other Issues or PRs

Fixes #24473

Brief description of what is fixed or changed

To find the sign of the coefficient, earlier the code would just compare it to zero, leading to an error for an imaginary coefficient. Now, it uses could_extract_minus_sign.

Other comments

After this PR:

>>> print(-I*K(p))
-I*K(p)
>>> print(I*K(p))
I*K(p)
>>> print(K(p))
K(p)
>>> print(-K(p))
-K(p)

Question: should I add tests for these?

Release Notes

• tensor
  • Fixed bug in printing TensMul.

Printing of a tensor raises an error if its coefficient is imaginary:

>>> from sympy.tensor.tensor import TensorIndexType, tensor_indices, TensorHead
>>> from sympy import I
>>> R3 = TensorIndexType('R3', dim=3)
>>> p = tensor_indices("p", R3)
>>> K = TensorHead("K", [R3])
>>> print(K(p))
K(p)
>>> print(I*K(p))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.10/site-packages/sympy/core/_print_helpers.py", line 29, in __str__
    return sstr(self, order=None)
  File "/usr/lib/python3.10/site-packages/sympy/printing/printer.py", line 373, in __call__
    return self.__wrapped__(*args, **kwargs)
  File "/usr/lib/python3.10/site-packages/sympy/printing/str.py", line 1001, in sstr
    s = p.doprint(expr)
  File "/usr/lib/python3.10/site-packages/sympy/printing/printer.py", line 293, in doprint
    return self._str(self._print(expr))
  File "/usr/lib/python3.10/site-packages/sympy/printing/printer.py", line 332, in _print
    return printmethod(expr, **kwargs)
  File "/usr/lib/python3.10/site-packages/sympy/printing/str.py", line 486, in _print_TensMul
    sign, args = expr._get_args_for_traditional_printer()
  File "/usr/lib/python3.10/site-packages/sympy/tensor/tensor.py", line 3872, in _get_args_for_traditional_printer
    if (self.coeff < 0) == True:
  File "/usr/lib/python3.10/site-packages/sympy/core/decorators.py", line 236, in _func
    return func(self, other)
  File "/usr/lib/python3.10/site-packages/sympy/core/expr.py", line 376, in __lt__
    return StrictLessThan(self, other)
  File "/usr/lib/python3.10/site-packages/sympy/core/relational.py", line 834, in __new__
    raise TypeError("Invalid comparison of non-real %s" % me)
TypeError: Invalid comparison of non-real I
>>> 

Sympy version: 1.11.1 Python: 3.10.9 OS: Arch Linux

References to other Issues or PRs

Brief description of what is fixed or changed

This is an attempt to test out jupyterlite-sphinx in the official doc, such that sympy tutorials and examples can be run from everywhere with web browser I try using the tutorials inside sympy/examples

Other comments

Release Notes

NO ENTRY

When evaluating $\nabla \mathbf{v}$, where $\mathbf{v}$ is a vector (defined below), the Del operator appears to be incorrectly evaluated for cylindrical coordinates. (It is also incorrect in spherical coordinates).

import sympy as sp
from sympy.vector import CoordSys3D, Del

R = CoordSys3D('R', transformation='cartesian', vector_names=("i", "j", "k")) # rectangular coordinates
C = CoordSys3D('C', transformation='cylindrical', vector_names=("e_r", "e_θ", "e_z"),
                                                  variable_names=('r', 'θ', 'z'))     # cylindrical coordinates

t = sp.symbols('t')                             # time

v_r = sp.Function('v_r')(t, C.r, C.θ, C.z)      # in general these components are functions of time and position
v_θ = sp.Function('v_θ')(t, C.r, C.θ, C.z)
v_z = sp.Function('v_z')(t, C.r, C.θ, C.z)

v = v_r*C.e_r + v_θ*C.e_θ + v_z*C.e_z

Del_v = Del()(v)

for coeff in [C.e_r, C.e_θ, C.e_z]:
    _ = Del()(v).coeff(coeff).expand()

    display(coeff)
    display(_)
    display(_.doit())

Output:

$$ \mathbf{\hat{e_r}_{C}} $$

$$ \left(\frac{\partial}{\partial \mathbf{{r}{C}}} v{r}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e_r}{C}} + \left(\frac{\partial}{\partial \mathbf{{r}{C}}} v{z}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e_z}{C}} + \left(\frac{\partial}{\partial \mathbf{{r}{C}}} v{\theta}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e\theta}_{C}} $$

$$ \mathbf{\hat{e_\theta}_{C}} $$

$$ \frac{\left(\frac{\partial}{\partial \mathbf{{\theta}{C}}} v{r}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e_r}{C}} + \left(\frac{\partial}{\partial \mathbf{{\theta}{C}}} v{z}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e_z}{C}} + \left(\frac{\partial}{\partial \mathbf{{\theta}{C}}} v{\theta}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e\theta}{C}}}{\mathbf{{r}{C}}} $$

$$ \mathbf{\hat{e_z}_{C}} $$

$$ \left(\frac{\partial}{\partial \mathbf{{z}{C}}} v{r}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e_r}{C}} + \left(\frac{\partial}{\partial \mathbf{{z}{C}}} v{z}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e_z}{C}} + \left(\frac{\partial}{\partial \mathbf{{z}{C}}} v{\theta}{\left(t,\mathbf{{r}{C}},\mathbf{{\theta}{C}},\mathbf{{z}{C}} \right)}\right)\mathbf{\hat{e\theta}_{C}} $$

The output above is correct in the $r$ and $z$ directions, but in the $\theta$ direction, the derivatives of the unit vectors $ \mathbf{e}r $ and $ \mathbf{e}\theta $ are not properly evaluated.

$$ \mathbf{e}_r = \cos{(\theta)} \mathbf{e}_x + \sin{(\theta)} \mathbf{e}_y $$

$$ \mathbf{e}_\theta = -\sin{(\theta)} \mathbf{e}_x + \cos{(\theta)} \mathbf{e}_y $$

$$ \frac{\partial}{\partial \theta} \left(\mathbf{e}_r \right) = -\sin{(\theta)} \mathbf{e}_x + \cos{(\theta)} \mathbf{e}y = \mathbf{e}\theta $$

$$ \frac{\partial}{\partial \theta} \left(\mathbf{e}_\theta \right) = -\cos{(\theta)} \mathbf{e}_x - \sin{(\theta)} \mathbf{e}_y = -\mathbf{e}_r $$

Where as Del()(v) seems to evaluate the derivatives as:

$$ \frac{\partial}{\partial \theta} \left(\mathbf{e}r \right) = \frac{\partial}{\partial \theta} \left(\mathbf{e}\theta \right) = 0 $$

References to other Issues or PRs

Fixes #24462

Brief description of what is fixed or changed

The electron rest mass (symbol: me) is the mass of a stationary electron, also known as the invariant mass of the electron. It is one of the fundamental constants of physics.

Other comments

Release Notes

NO ENTRY

The electron rest mass (symbol: me) is the mass of a stationary electron, also known as the invariant mass of the electron. It is one of the fundamental constants of physics. It has a value of about 9.109×10−31 kilograms It is not in physics.units should we add it.