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.