test('') fails on master ? test('') seems to fail on master. I'm running Python3.5, sympy-dev, MacOS 10.15.3


Improvement to printing symbolic matrix slices Printing of slices seems sub-optimal, so here are my proposed changes. Let me know if any of this is controversial. Assuming A[:, :] unchanged A[5:, 5:] A[::2, ::2] unchanged A[0, 0] A[0, 0] All of these would affect the str/pretty/latex printer. I see no reason to drop the '0' from the start of a slice, but not 'n' at the end, especially since we otherwise never hint at the dimensions of the matrix while printing. Also, brackets are missing, making slices of composites display in an unfortunate way: (A + B)[:2, :2] A + B[:2, :2]


improvement The method can be significantly improved by using the Knuth-Cohen bound instead. After our research with Prof. Ag.Akritas we have implemented the Knuth-Cohen bound among others, and compare them among dozens of polynomials with different degree, density and coefficients range. Considering the results and the feedback from Mr.Kalevi Suominen, our proposal is that the mignottebound should be replaced by the knuth-cohen bound. Also, for mutli-variants polynomials should be replaced appropriately.


srepr not printing dict and set properly prints the element in and correctly. However, prints the elements in and wrong. Is this behavior intended? If it isn't, fixing it will be an easy job.


Rewrite sign as abs In sympy the function is defined as for all complex non-zero . There should be a way to rewrite the sign in terms of e.g.: I'm not sure how the possibility of being zero should be handled currently we have Maybe should be as well. Otherwise maybe rewrite as Abs would have to be careful about the possibility of the arg being zero (that would make the rewrite fail in most cases).


Strange/wrong? behaviour of subs with ConditionSet / ImageSet I'm not sure what to think of the following: The first two outputs are completely as expected, but if I construct a similar ConditionSet with an ImageSet instead of a FiniteSet, a plain gives a strange result (). It's as if the bound variable of the ConditionSet were mistaken for a . Only after having typed the above, I found issue , so I'd like to add that a subs on the plain ImageSet is working as intended:


sympy 1.6.1 ? Hi, is there any plan on releasing 1.6.1, just like we had 1.5.1 shortly after 1.5? , but the patches we've submitted have already been merged into SymPy master, and we're looking forward to jump to 1.6. Thanks!


kernS: 'kern' referenced before assignment from import kernS text = "(2*x)/(x-1)" expr = kernS(text) // hit = kern in s // UnboundLocalError: local variable 'kern' referenced before assignment


GeneratorsError raised when creating element of fraction field of polynomial ring I see this construction is not possible while it can be constructed from an element of The same error raises for an element of So this can be relevant


Dagger() * IdentityOperator() is not simplified As discussed on the mailing list the following does not work.


Wrong answer when using "linsolve" to solve a system of linear equations ! I can get the correct answer when I use the function "solve". However, when I use the "linsolve", it returns a wrong answer to me. It is a very serious bug and I hope that your team can fix it. The following part is my code: (I also upload it with the name "".)


sylowsubgroup() IndexError I use sympy 1.6.1, with numpy 1.18.5, scipy 1.4.1, under Python '3.8.5 (default, Aug 5 2020, 09:44:06) [MSC v.1916 64 bit (AMD64)]'. The code that I run as the following gives IndexError for sylowsubgroup(): from sympy.combinatorics import DihedralGroup, PermutationGroup, Permutation G = DihedralGroup(18) S2 = G.sylowsubgroup(p=2) Traceback (most recent call last): File "<input", line 7, in <moduleFile "D:\anaconda38\envs\default\lib\site-packages\sympy\combinatorics\", line 4370, in sylowsubgroup blocks = self.minimalblocks() File "D:\anaconda38\envs\default\lib\site-packages\sympy\combinatorics\", line 2207, in minimalblocks del numblocks[i], blocks[i] IndexError: list assignment index out of range The same error shows up as well when I set: G = DihedralGroup(2*25) S2 = G.sylowsubgroup(p=2)


() should calculate the velocity if possible If you specify the orientation of two reference frames and then ask for the angular velocity between the two reference frames the angular velocity will be calculated. But if you try to do the same thing with velocities, this doesn't work. See below: The expected result of the should be: I think that this is possible. Maybe there is a reason it isn't implemented. But we should try to implement it because it is confusing why this works for orientations and not positions.


Lambdify does not identify frac() Hello, this is my first issue ever. The following code gives the following error If there exists a fix, please let me know. Replacing () with just frac() does not help either.


Warn the user when trees of points or trees of reference frames are not self consistent. has Point and ReferenceFrame. These can be positioned and oriented relative to objects of their same type, respectively. The user is expected to define relative positions and orientations in a consistent manner and the relationships among the objects should be tree graphs. It would be helpful to warn the user if they set positions and orientations that create incorrect graphs, for example adding a cyclic branch; the graphs should be acyclic. You can also create inconsistencies when it comes to calculating velocities and angular velocities, which is done automatically if possible. Here is a point example: The velocities of O in N are different depending on if you calculate based on P or Q. It is also impossible to choose between P or Q. Right now, P or Q will be chosen based on which comes first in . We should warn the user that this graph is inconsistent when trying to calculate the velocity of O in N. This same thing can happen with ReferenceFrame. I suspect there will be issues when users have kinematic loops and may want to define the loop of point positions that specify the loop. Currently, that is not supported. If you specify a loop through a succession of setpos() or locatenew() calls, you get an invalid point tree. Kinematic loops have to be dealt with by adding the algebraic equation and forming DAEs instead. These warnings need some careful thought. The first step would be to define precisely what graphs are consistent and non consistent, in terms of 's capabilities and design. Once that is defined, some methods to check for consistencies can be . There will be inconsistencies related purely to position and orientation as well as inconsistencies related to the automated calculation of velocities. There is discussion in this PR that is relevant:


Use Str instead of Symbol for name of MatrixSymbol <!-- Your title above should be a short description of what was changed. Do not include the issue number in the title. --<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact format, e.g. " (see for more information). Also, please write a comment on that issue linking back to this pull request once it is open. --<!-- Write the release notes for this release below. See 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 will store Str in its first argument. <!-- END RELEASE NOTES --


partitions() reusing the output dictionaries The partitions() iterator in sympy.utilities.iterables reuses the output dictionaries. There is a caveat about it in the docstring. I'm wondering if it's really that important for it to do this. It shouldn't be that much of a performance loss to copy the dictionary before yielding it. This behavior is very confusing. It means that something as simple as list(partitions()) will give an apparently wrong result. And it can lead to much more subtle bugs if the partitions are used in a nontrivial way.


Lens makers formula Currently lens maker formula is limited to thin lens. It should also work for plano- lenses(plano-concave and plano convex) and thick lens.


0-oo produces 0, the documentation says it should produce zoo Using SymPy 1.5.1, evaluate produces . The documentation for the Pow class states that it should return , aka


RecursionError occured while convert sympy expression to latex when expression like Pow(1/n,-1) Hello, Thanks for awesome library :) I find issue but I can't figure out why the following phenomena occur, so I write an issue. I use and i tried to latex function to change sympy expression to latex. But RecursionError occured while change Pow(Rational(1,n), evaluate=False) result to latex. It error occured only when (numerator = 1 and denominator=Positive integer bigger than 1) or (numerator = -1 and denominator=Negative integer lower than -1) . Below is code of i runned:


Inconsistent behavior for sympify/simplify with ceiling In sympy v1.5.1: In sympy v.1.6.2: Is there a way to ensure that the behavior is consistent, even though evaluate is equal to when parsing?


Result from cleardenoms() prints like zero poly but behaves wierdly (due to unstripped DMP) The was the immediate cause of the ZeroDivisionError in . Calling on a complicated constant poly that turns out to be zero: The result prints like the zero polynomial but behaves inconsistently: ( points out this is a bug in ), but other Poly methods don't handle very well. e.g. Also sometime in the last year Poly.primitive has been changed to slightly better handle this bad poly. but in earlier versions of SymPy: which was the cause of the ZeroDivisionError reported in . Looking at the underlying DMP, there is an unstripped leading 0 in the list representation of the Poly which should be


convertto seems to combine orthogonal units Tested in sympy 1.4, not presently in a position to install 1.5+. Simple example. Consider . The convertto behavior is odd: I would expect the unchanged original expression back, an expression in terms of base units, or an error. It appears that convert_to can only readily handle conversions where the full unit expression is valid. Note that the following three related examples give sensible results:


simplify() returns wrong result when applied to a certain trigonometric expression The function from sympy returns a wrong result when applied to the following trigonometric expression: <img src="\cos\left(\frac{\beta}{2}\right) \sin\left(\frac{\beta}{2}\right) \cos(\beta) \cos(\gamma)^2 \sin(\gamma)"The latter gets simplified to: <img src="\frac{\cos(2\beta - 2\gamma) - \cos(2\beta %2B 2\gamma)}{16}"instead of: <img src="\cos(\gamma)\frac{\cos(2\beta - 2\gamma) - \cos(2\beta %2B 2\gamma)}{16}"Here is a piece of code that reproduces the issue: Python version: 3.8 SymPy version: 1.6.2 simplify() returns wrong result when applied to a certain trigonometric expression The function from sympy returns a wrong result when applied to the following trigonometric expression: <img src="\cos\left(\frac{\beta}{2}\right) \sin\left(\frac{\beta}{2}\right) \cos(\beta) \cos(\gamma)^2 \sin(\gamma)"The latter gets simplified to: <img src="\frac{\cos(2\beta - 2\gamma) - \cos(2\beta %2B 2\gamma)}{16}"instead of: <img src="\cos(\gamma)\frac{\cos(2\beta - 2\gamma) - \cos(2\beta %2B 2\gamma)}{16}"Here is a piece of code that reproduces the issue: Python version: 3.8 SymPy version: 1.6.2


Symbol instances have dict since 1.7? In version 1.6.2 Symbol instances had no attribute This changes in 1.7 where now exists (and returns an empty dict) I may misinterpret this, but given the purpose of , I assume this is a bug, introduced because some parent class accidentally stopped defining .


inaccurate rendering of pi**(1/E) This claims to be version ; I just merged from the project master, so I hope this is current. I didn't notice this bug among others in LaTeX and str not fooled:


S(0.0) == S.false returns True This issue is related to those listed in . As shown by comparing to returns 2 different results depending on the order in which they are compared: Based on the results of comparison to : I assume we would want to return True as well?


pprint unicode does not format subscripts on Greek letters Good: [ -t₀⋅w₀ -t₁⋅w₀ -t₂⋅w₀] Bad: [ -t₀⋅ω0 -t₁⋅ω0 -t₂⋅ω0]


does not understand how to simplify complex arguments Just learned about the refine-function, which would come in handy frequently for me. But does not recognize that argument functions simplify for real numbers. I cann't find any open issues identifying this. Easy to fix, though.


printSingularityFunction() got an unexpected keyword argument 'exp' On a Jupyter Notebook cell, type the following: Then: The following error appears:


Results diverge when use on a matrix or its elemetns create a one-element matrix A as below: when use on matrix A: when use on the single element of A: but if use method on A, the result is the same as above: is this a bug or supposed behavior of matrix calculus?


Improve asrelational for Range Ranges don't have a rule in that file but they are complicated unless their steps are both the same and the modulus of the starting values relative to the step is the same. Note that the following is wrong (but is outside the scope of this PR): It should be Originally posted by in


Doctest failure in See discussion in . CC There was a doctest failure but the test was disabled in to unblock CI. The cause of the failure remains unfixed though. The failure was:


don't canonicalize imageset based on Float While writing this about how to get something resembling a float-version for range to work, I tried to think about how I would do this in SymPy. Although Floats present their own difficulties, there is canonicalization being done with expressions that makes this even worse: That last result should represent an error. The reason it happens is because is replaced with : So while canonicalization is OK for Rationals, it should not be done to Floats. Working around this issue, here is a version of that might work for SymPy:


Unexpected when using simple for particular expressions I am seeing weird behavior with for particular expressions with hyperbolic sinusoids with piecewise arguments. When applying , I obtain an unexpected . For context, I was umbrella-applying a casting from int to float of all int atoms for a bunch of random expressions before using a tensorflow lambdify to avoid potential tensorflow type errors. You can pretend the expression below has a at the end, but below is the MWE that I could produce. See the expression below, and the conditions in which the exception arises. Sympy version: I am not really sure where the issue is, but I think it has something to do with the order of assumptions in this specific type of expression. Here is what I found- The error only (AFAIK) happens with or in place of , otherwise it succeeds The error goes away if removing the division by The error goes away if removing (but stays for most unary functions, , , etc.) The error only happens with real symbols for and ( does not have to be real) Not too sure how to debug this one.


powdenest(sqrt(sin(x)2), force=True) does not work Since gives , I would expect to be .


diffgeom.CoordSystem.transform with indirect relation raises KeyError Below code is a minimal example for an indirect transform via a temporary intermediate coordinate system. raises a KeyError. MWE: This raises a KeyError. DEBUGGING:


linsolve fails simple system of two equations Any thoughts on why these don't all return the same solution? Thanks!


for , Although we have fixed , it should be extended further for . The behavior for was to expand it in denominator with , so it could be taken as a reference.


parseexpr with localdict I have 2 expressions that differ only in E*x` and I want to parse it: Right, but if And Thank you!


bug in is_subset(Reals) Solving issue has given rise to another bug. Now: This output is incorrect. Correct output is:


Latex parsing of fractions yields wrong expression due to missing brackets Problematic latex expression: is parsed to: . Expected is: . The missing brackets in the denominator result in a wrong expression. 1.8 1.6.2 root python3 Python 3.6.9 (default, Jan 26 2021, 15:33:00) [GCC 8.4.0] on linux Type "help", "copyright", "credits" or "license" for more information. from import parselatex parselatex("\frac{\frac{a^3+b}{c}}{\frac{1}{c^2}}") ((a3 + b)/c)/1/(c2)


Wrong Derivative kind attribute I'm playing around with the attribute. The following is correct: This one is wrong:


Bug: maximum recusion depth error when checking is_zero of cosh expression The following code causes a error when checked if it is zero:


Latex repr of CG with power does not render correctly There seem to be Latex rendering problems when a Clebsch-Gordan coefficient () is, for instance, squared: ! <details<summaryCode snippet</summary</detailsI ran this with Sympy v1.7.1 It could be that this is strictly speaking a Jupyter lab/notebook problem, because the that returns is (I think) valid syntax: Still, a simple fix for would be to wrap the in braces: <details<summaryResult in Jupyter</summary! <details<summaryCode snippet</summary</details</detailsRelated issues: and


Quaternion class has no overridden evalf method class has no overridden method.


itermonomials returns incorrect monomials when using mindegrees argument returns incorrect monomials when using optional argument For example, the following code introduces three symbolic variables and generates monomials with max and min degree of 3: The code returns , when it should also return monomials such as that also have total degree of 3. This behaviour is inconsistent with the documentation that states that The monomials are also missing when is increased above .


LambertW displaying in jupyter lab When using JupyterLab and trying to raise LambertW function to some power (for example multiplying with itself) then it raises error when trying to display it. Same thing happens if I use sp.Pow() method as well. For example sp.Pow(sp.LambertW(2), 2) causes the error as well.


Issues with Latex printing output in second quantization module There are Latex rendering problems within the "secondquant" module, as it does not correctly interpret double superscripts containing the "dagger" command within Jupyter Notebook. Let's see a minimal example So, it doesn't render correctly, and that's because the double superscript . It should be correct by adding curly brackets


imageset over Range does not work Simple example: It throws the exception while it tries to check where is the object.


If n is even, n**2/2 should also be even The following: should return , but it returns (of course, this is also an enhancement). That makes me think that perhaps symbolic integers should keep a more complex "assumptions" method, which generalizes "iseven" and "isodd" to instead contain a dictionary of primes that are known to divide that integer, mapping to minimum and maximum known multiplicity. I would like to think about it and post a proposition/plan, but I am not sure what is the correct github way of doing this. Updated evalisodd to handle more complex inputs Changed the function evalisodd to handle integer inputs that have a denominator, such as The example expression x is recognized by SymPy as an integer, but can be decomposed into n,m,and 1/2. My new function evaluates the oddness of each part and uses this to calculate the oddness of the entire integer. Addresses issue


Mod function lambdify bug Description: When lambdifying any function of structure like sympy moves the multiplier into the first argument of Mod, like , WHEN we specify This is an example from Sympy online shell


parse_expr partially evaluates under sqrt with evaluate=False Python 3.8.5 (default, Jul 28 2020, 12:59:40) [GCC 9.3.0] on linux with sympy v1.7 I was expecting to get: does not seem to propagate correctly, since the used sympy functions support on their own:


maint(ci): drop testing for Python 3.6 <!-- Your title above should be a short description of what was changed. Do not include the issue number in the title. --<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact format, e.g. " (see for more information). Also, please write a comment on that issue linking back to this pull request once it is open. -- describes adopting NEP 29 which would mean dropping support for Python 3.6 now. Drop testing in CI for Python 3.6 and PyPy 3.6 <!-- 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 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 --


Argument invariance of String Currently, the class does not support argument invariance like: , but instead uses the invariance . The former should hold for any subclass, which is.


IndexError in StrPrinter for UnevaluatedMul gives if coeffisneg(n[0]): IndexError: list index out of range


simpify gives with evaluate(False) crashes unexpectedly with However, it works without . Both of following commands work


lambdifying Heaviside(Min(x, y)) not working When the original issue in , the following becomes a problem leads to Seems like there is a problem having/generating select inside of select. leads to which causes a similar error gets rid of the in the Piecewise and works. Hence, it probably makes sense to try to detect the ITE in the Piecewise and if so, rewrite it as And and/or simplify/simplify_logic. Related to While writing this issue, I figured out the solution. Will keep this to not have to explain in the PR why I did what I did...


cse() has strange behaviour for MatrixSymbol indexing Example: This gives the following output: and are just copies of the matrices and , respectively.


PythonCodePrinter doesn't support Min and Max We can't generate python code for the sympy function Min and Max. For example: the output is: Similar to issue , we should add following methods to PythonCodePrinter:


x not in QQ.frac_field(1/x) Again, probably it should.


Gaussian Optics / Refractive index not considered Dear sympy maintainers, please correct me, if I am wrong, but I fear that the beam waist in class is not correctly computed. From the source: def w0(self): """ The beam waist (minimal radius). See Also w : the beam radius at intensity Examples from import BeamParameter p = BeamParameter(530e-9, 1, w=1e-3) p.w0 0. """ return sqrt() After transmission through a surface with the refractive index changing, the Rayleigh length zr would change, while wavelength stays the same. According to this implementation, w0 changes, which is not physical. If I might help to solve this, I would be happy to contribute. However, I have not a very good understanding of sympy, and this code is interfaced of course with sympy. Best regards, Lukas Gaussian Optics / Refractive index not considered Dear sympy maintainers, please correct me, if I am wrong, but I fear that the beam waist in class is not correctly computed. From the source: def w0(self): """ The beam waist (minimal radius). See Also w : the beam radius at intensity Examples from import BeamParameter p = BeamParameter(530e-9, 1, w=1e-3) p.w0 0. """ return sqrt() After transmission through a surface with the refractive index changing, the Rayleigh length zr would change, while wavelength stays the same. According to this implementation, w0 changes, which is not physical. If I might help to solve this, I would be happy to contribute. However, I have not a very good understanding of sympy, and this code is interfaced of course with sympy. Best regards, Lukas


decompogen doesn't like Min/Max perhaps related to and Add Min/Max support for decompogen <!-- Your title above should be a short description of what was changed. Do not include the issue number in the title. --<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact format, e.g. " (see for more information). Also, please write a comment on that issue linking back to this pull request once it is open. -- Before addition --- After addition --- <!-- Write the release notes for this release below. See 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 --solvers Added / support for . <!-- END RELEASE NOTES --


sympy.Array([]) fails, while sympy.Matrix([]) works SymPy 1.4 does not allow to construct empty Array (see code below). Is this the intended behavior?


polytopeintegrate and maxdegree Trying to build on the examples as ` works but fails: Is that the expected behavior? Why? Thanks!


display bug while using pretty_print with object in the terminal The following code jumbles some of the outputs in the terminal, essentially by inserting the unit vector in the middle - Output:


Python code printer not respecting tuple with one element Hi, Thanks for the recent updates in SymPy! I'm trying to update my code to use SymPy 1.10 but ran into an issue with the Python code printer. MWE: SymPy 1.9 and under outputs: But SymPy 1.10 gives Note the missing comma after that causes an integer to be returned instead of a tuple. For tuples with two or more elements, the generated code is correct: In SymPy 1.10 and under, outputs: This result is expected. Not sure if this is a regression. As this breaks my program which assumes the return type to always be a tuple, could you suggest a workaround from the code generation side? Thank you.


Dimensionless number in exponent not recognized as dimensionless in collectfactoranddimension The following raises an error: returns: Using does not raise an error here: Added fix for wrong dimension calculations in case of some mathematical functions …al functions <!-- Your title above should be a short description of what was changed. Do not include the issue number in the title. --<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact format, e.g. " (see for more information). Also, please write a comment on that issue linking back to this pull request once it is open. -- Fixed the return value for the function collectfactorand_dimension(). Previous return value led to wrong dimensional evaluation for expressions containing predefined mathematical functions. <!-- Write the release notes for this release below. See 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 -- Fixed dimensional evaluation for expressions containing predefined mathematical functions. <!-- END RELEASE NOTES --


bug with HNF removing rows I expect to give but instead I get It seems to be falsely identifying my matrix as rank-deficient and removing the row when I try to achieve a row-style HNF using flips and transposes.


Using symbols to create functions doesn't work if there is an extra layer of parentheses Sympy version == 1.10.1 Using to create symbol-like objects like instances of as shown in the creates objects of class instead of if there is an extra layer of parentheses. The extra layer of parentheses are necessary to deconstruct the output as separate tuples. Running the code: <class ''<class ''


idiff should use (or better) should not use full blown to implicitly solve for a derivative which will appear in a linear fashion. would be better to use or else simply use a low-level linear solver for the calculation. The following equation takes too long to solve for : The solution can be found as


recursion overflow even for for small As title, I am trying to run for and , but it throws a : I am not sure if this classifies as a bug, but it seems unintended especially since 10^6 is such a small number and has a "easy" factorisation (10^6 = 2^6 * 5^6).


() incorrectly reverses order of leading uncontracted gamma matrices The kahanesimplify() function applies such as to simplify products of gamma matrices in which contracted matrices occur. Leading gamma matrices without contractions should be unaffected, but a bug causes such leading terms to be prepended in reverse order. The bug is illustrated by the following example: The result is Both and should simplify to , but the order of and is flipped in the second case due to the bug. I found the source of the bug and it is simple to fix. In the leading matrices are removed at the beginning of the function and then inserted at the start of the product at the end of the function, and the insertion loop is just backward. I'll generate a pull request for this shortly.


returns Contains This is wrong because Contains is not a set (it's a boolean). It results in failures in other places because it doesn't have asrelational (since it isn't a set). For instance, from


SI.collectfactoranddimension() cannot properly detect that exponent is dimensionless How to reproduce:


Cannot parse Greek characters (and possibly others) in parsemathematica The old Mathematica parser in the package was able to parse e.g. Greek characters. Hence the following example works fine: As of SymPy v. 1.11, the function is deprecated, and is replaced by . This function, however, seems unable to handle the simple example above: This appears to be due to a bug in , which is why I have opened this issue. Thanks in advance! Cannot parse Greek characters (and possibly others) in parsemathematica The old Mathematica parser in the package was able to parse e.g. Greek characters. Hence the following example works fine: As of SymPy v. 1.11, the function is deprecated, and is replaced by . This function, however, seems unable to handle the simple example above: This appears to be due to a bug in , which is why I have opened this issue. Thanks in advance!


Bug in expand of TensorProduct + Workaround + Fix The expansion of a TensorProduct object stops incomplete if summands in the tensor product factors have (scalar) factors, e.g. This is clearly not the expected behaviour. It also effects other functions that rely on .expand(tensorproduct=True), as e.g. qapply() . Repeat .expand(tensorproduct=True) as may times as there are tensor factors, resp. until the expanded term does no longer change. This is however only reasonable in interactive session and not in algorithms. .expand relies on the method TensorProduct.evalexpandtensorproduct(). The issue arises from an inprecise check in TensorProduct.evalexpandtensorproduct() whether a recursive call is required; it fails when the creation of a TensorProduct object returns commutative (scalar) factors up front: in that case the constructor returns a Mul(cfactors, TensorProduct(..)). I thus propose the following code fix in TensorProduct.evalexpandtensorproduct() in I have marked the four lines to be / modified: The fix splits of commutative (scalar) factors from the tp returned. The TensorProduct object will be the one nc factor in nc_part (see constructor), if any. Note that the constructor will return 0 if a tensor factor is 0, so there is no guarantee that tp contains a TensorProduct object (e.g. TensorProduct(U-U, U+V).


collectfactorand_dimension does not detect equivalent dimensions in addition Code to reproduce: Results in:


Numerical error on conversion of coulomb to statcoulomb It should be fixed as : Numerical error on conversion of coulomb to statcoulomb It should be fixed as :


Floor division with sympy.Integer gives: Argument of Integer should be of numeric type, got floor(1024/s0) gives oddly enough, it works if the lhs is a plain Python int. Floor division with sympy.Integer gives: Argument of Integer should be of numeric type, got floor(1024/s0) gives oddly enough, it works if the lhs is a plain Python int.


is broken on PermutationGroups The issue is in the internal function, where it handles the case of a : When is an inverted generator, the test fails. I think the whole thing can be greatly simplified.


incorrect on "unnamed" S3 If we construct a group that's isomorphic to S3, but don't use the function to form it, then is coming up . I think the property method is fine up until the end. It ends like this: Let's talk about what's happening here. First, let be the group, given by generators . For any prime dividing the order of the group, let be the subgroup generated by the th powers of the given generators. The for-loop is saying, "If is cyclic, then for all dividing the order of the group, ," which I think is true. Fine. But the last three lines, after the for-loop, want to say the converse is also true, which it must not be, since appears to be a counterexample. The question is whether there's a good way to save this. In other words, there is always the last ditch, brute force method, where we just look through all the elements of the group for a generator: but it seems like we almost had a better method here, and it would be nice if we could patch it. I'm wondering if anyone whose group theory is not as rusty as mine might know a way. If is the subgroup of consisting of all products of th powers of elements of , it seems like the theorem we wanted might have been true with in place of ? I don't know. But it does seem like the discrepancy between and might be the issue here. In the case of presented as , is just which does have index (hence the failure), whereas and has index , and the test would not have failed.


not accepting symbols The method is supposed to let you set the symbols you want to use, but, as it stands, either you pass the wrong number of symbols, and get an error message, or you pass the right number of symbols, and it ignores them, using instead:


Rational calc value error python 3.11, sympy 1.11.1 when calc Rational('0.5', '100'), the value is 1/; but Rational(0.5, 100) the value is 1/200, this value is the true value, and the version of sympy 1.8 is normal


MatMul(x.T, OneMatrix(k, 1)).diff(x) causes RecursionError The following code creates a RecursionError due to a missing array_derive registration for OneMatrix:


The evaluate=False parameter to is ignored for relationals See also and This inequality evaluates even though is given: The result that should be returned is:


Stats: Matrix Normal Distribution returns wrong probability density function As explained on the , the PDF of Matrix Normal Distribution is as follows: ! When initializing a matrix Normal Distribution in Sympy with simple parameters (as mentioned in the docs), the PDF you get is: Whereas the actual PDF should be: References: The difference is in the constant of the PDF and should be a simple issue to solve.


Bug with milli prefix What happened: What I expected to happen: milliW should evaluate to milli watts / mW or more generally times some unit evaluates to the number 1. I have tried this with Watts and Volts, I'm not sure what other cases this happens. I'm using sympy version 1.11.1-1 on Arch Linux with Python 3.10.9. If you cannot reproduce I would be happy to be of any assitance.