with existing doesn't exit easily Describe the bug I've attached a screenshot in the screenshots section which I think explains the bug better. I'm running in a folder with a already existing. It says "Please enter a new root path name (or just Enter to exit)". However, upon pressing 'Enter' it returns an error message "Please enter a valid path name". To Reproduce Steps to reproduce the behavior: Expected behavior After pressing Enter, sphinx-quickstart exits. Your project n/a Screenshots ! I press Enter for the first prompt. Environment info OS: Ubuntu 20.04 Python version: Python 3.8.5 Sphinx version: sphinx-build 3.2.1 Sphinx extensions: none Extra tools: none Additional context I had a quick search but couldn't find any similar existing issues. Sorry if this is a duplicate.


Man page using :samp: with braces - font doesn't reset There are issues with the man page rendering when using :samp: The font change doesn't reset after the closure of the samp but runs onto subsequent lines until certain 'resetting' elements are encountered, such as a bullet, heading and probably others I haven't tested for. :samp: is ok. HTML and Latex (pdf) formats are also unaffected by this issue. MWE included with screen shot. Text that should be plain. A bullet that should be plain. And back to normal. :samp: More text that should be plain. A bullet that should be plain. And back to normal. :samp: All ok on this line. !


1-element tuple rendered incorrectly Describe the bug This is a followup to which has been addressed in . However the special case of a 1-element tuple is still not handled correctly. is rendered as , but should keep the trailing comma. To Reproduce Add a testcase at


Autodoc still using typehint types in properties Describe the bug Despite being set to , properties have type hints rendered in the output. To Reproduce Steps to reproduce the behavior. Download the zip below and go to then run Expected behavior No type hints in the output. Your project Screenshots ! Environment info OS: Windows 10 Python version: 3.9.2 Sphinx version: 4.0.2 Sphinx extensions: Extra tools: N/A Additional context Issue discovered in a real project (edit: I removed it using CSS).


Add an option to not use intersphinx references as a fallback That intersphinx references are used as fallbacks if a reference is not available in a project recently caused us a problem. We have a site () which is the latest build of . We use intersphinx as follows, so we can link to the latest documentation in some sections: Our docs included a label () so this reference was available on . This label was removed on a branch, along with one of the two references to this label. In this case we would expect that building the branch would fail, as there is a reference to a label which doesn't exist. Unexpectedly, the branch built successfully, because the label was found in as a fall back when it was not found locally. The branch was merged, and then later, when changed (because was built again) builds stopped working because there was a reference to a non-existent label. It would be good to have an option to not fall back, maybe something like .


Methods decorated with and do not get documented. EDIT: The problem seems to be that returns , thus sphinx can just lookup . However, returns the type of the returned object, since essentially, a ends up behaving like a class attribute. So Sphinx doesn't really have a chance to extract the docstring. EDIT 2: Seems like this will get fixed in python 3.10, cf. I will try to test this with the beta release. That is, since python version 3.9 we can write code like However, sphinx does not seem to document any such methods (regular decorated methods get documented just fine.) The following methods were erroneously not documented: - - - Methods that are decorated with both and should be documented appropriately. No response Ubuntu 20.04.2 LTS 6 3 , No response No response


PEP 585 type hints not rendered correctly If you use a PEP 585 generic as an annotation i.e. , autodoc renders the annotation as rather than , this behaviour differs from using which renders as expected. Fixing this is quite simple as far as I can tell, just needs to check if the annotation has and if it does, return An annotation of to be rendered as ! Mac Python 3.9.3 1 autodoc No response No response


github linkcheck anchor change in 4.1.0 break some usage Given a link like: in a github doc, with release 4.1.0 this will fail with linkcheck, while previously it worked. It passes. No response Linux 5 0 No response No response The relevant change happened in Failing test logs:


Missing support for GNU extension types like or I'm currently working on the transition of the GNU C compiler (GCC) manuals and I noticed there are unsupported C extensions like: where I see the following parsing error: Right now, there's some special casing for e.g. 'unsigned' type: One possible fix is adding the mentioned C extension handling for the following types: or I can see a domain parser can become public via an API entry point: What do you think?


Cross-references don't work in property's type annotations A documented type in property's type annotation does not get cross-referenced: I expected the documented type in property's type annotation to be cross-referenced. Here's a link to the generated docs: https://sphinx-issue- Windows 10, Ubuntu 18.04 7, 3.8, 3.9 2 No response No response


Nitpick flags Literal annotation values as missing py:class When a value is present in a type annotation as , sphinx will treat the value as a . With nitpick enabled, values like end up failing, because is not a class. This is a problem for builds which want to use to catch doc errors. Setup a simple function which uses Literal, then attempt to autodoc it. e.g. I've pushed an example to . Just run with available to see the failing build. (or whatever literal value) should be present in the type annotation but should not trigger the nitpick warning. No response Linux 8, 3.9 2 autodoc No response No response


Incorrect base class detection I have a chain of subclasses, like A -B -C -D. When I document class D, it lists the base class as A instead of C. I would expect the base class to be the direct super class. No response macOS 10.15.7, Linux (whatever RtD uses) 11 1, 4.0.2 No response I don't think this is the same as because I can reproduce it with 4.0.1 too. Could be related to . For a class like , even though the super class is , the base class is listed as .


Inherited classes not correctly documented when mocked We're experiencing an issue when documenting classes that inherit mocked classes. However, classes which inherit other classes from our own package are ok. This issue appears to be dependent on the version: : Everything is OK. : Classes that inherit mocked classes are not documented. (see ). This is fixed in . : The previously missing classes are now documented, but there is a problem with the "Bases" section in the docs. Example: In the docs for in this readthedocs build https://seldon--, the base class is listed as "Bases: " instead of "Bases: ". The "Bases" section should report not . i.e. see https://seldon-- ! ! Ubuntu 18.04 (used by readthedocs/build:6.0) 11 ["", "", "", "", "", "", "", "", "", "sphinxautodoctypehints", "", "nbsphinx", "nbsphinxlink", "mystparser"] No response demo PR: readthedocs demo build: https://seldon--


python bases in packages - follow up on Is your feature request related to a problem? Please describe. Same problem as described in Describe the solution you'd like sphinx checks if the base class is documented somewhere. If yes, it inserts the reference to the corresponding page automatically. Describe alternatives you've considered As originally proposed in , allow to return a list of strings that will be appended to Additional context was marked as but that PR unfortunately doesn't solve the problem: While I now can return a different base class, I still can't control the text of the hyperlink for that class. With being allowed to return strings, one could just return something like telegram.TelegramObject` PS: maybe we can just reopen and continue discussion there …


autodoctypehintsdescriptiontarget not working with Napoleon I was trying to use the config option combined with the Napoleon plugin (using Google style). The return types were missing from the resulting documentation. Just generate the documentation using Napoleon and the config options: Generate the documentation of a function with the following docstring: As the return is specified, the return type should be present in the documentation, either as a rtype section or as part of the return description. ! Win 8 0 '', '', '', '', '', No response No response


An index entry with parens was registered for directive with option An index entry with parens was registered for directive with option. It should not have parens. An index entry for the property should not have parens. N/A <img width="528" alt=" 2021-10-03 13 00 53" src="https://user-"Mac 6 HEAD of 4.x No response No response No response


needsextensions checks versions using strings The check is handy for verifying minimum extension versions, but it only checks versions in a 'string-like' manner. This means any version 9 is not allowed for any check of something 1. That is, treated as string '0.6' '0.10', but treated as versions '0.6' < '0.10'. Since Sphinx does the former, some extension versions may not be allowed when they should be. This passes just fine, because the requirements pin sphinx-gallery to 0.9. But if you then update to the current 0.10 release: results in a failure due to a "not new enough" version: sphinx-gallery 0.10.0 should be accepted if 0.6 is the minimum specified. No response Fedora 6 2 No response No response No response


Overridden classmethod documentation not inherited with autodoc The documentation for a classmethod in a parent class is not inherited by the method re-defined (without documentation) in a child class Module : Sphinx configuration : Documentation index : Build: Overridden classmethod to inherit documentation from parent class ! Ubuntu 20.04 8 0 returns the expected value


Nitpick flags Literal annotation values as missing py:class (with type hints in description) This is basically the same issue as , which was fixed in . However, I still get this issue when using . Comment out the line in and it is successful, as shown below (and removing the build artifacts to start fresh). No error, the build should succeed. See attachment in "How to Reproduce" section N/A - output is shown in "How to Reproduce" section Linux and Windows 9 0 , N/A This re-produces for me on both Linux and Windows. I think the source of it issue is probably from in since this function would otherwise be skipped if the type hints are left in the signature. But I haven't yet been able to track it all the way down to the error.


Re-opening : hexadecimal default arguments are changed to decimal I am experiencing the exact same problem as described in : hexadecimal default arguments are changed to decimal. Autodoc the following function: HTML result looks like this Hexadecimal defaults should not be converted to decimal, or at least there should be an option to enforce this behaviour. I'm afraid this is private No response Linux Ubuntu 20.04 10 0 autodoc, intersphinx, napoleon Chromium 94 No response


Support for fuzzy translations Problem Entries in po files that are currently marked as "fuzzy" are not used in "mo" files. The original source language is used instead of the translated language. Fuzzy translations are translations that in general need to be reviewed by a translator. For example all machine translations could be marked as fuzzy. It would be desirable to let the user decide whether to include these fuzzy translations in the generated documentation. Proposed solution Add a new configuration parameter "usefuzzytranslations". Change in line 72 of the file writemo(filemo, po) to writemo(filemo, po, usefuzzytranslations) Writing mo files with fuzzy translations is supported by the babel package, as can be seen in the documentation:


Add a way to defer loading of MathJax Is your feature request related to a problem? Please describe. It is quite tricky to configure MathJax to work with Sphinx currently. Sphinx loads MathJax asynchronously since and While this was fine for MathJax 2, because of the special kind of blocks mentioned in , it doesn't work well with MathJax 3. Indeed, in MathJax 3, MathJax expect a config block to be present before MathJax is loaded. Sphinx 4 parameter: This assumes that the is a simple dictionary, which isn't sufficient: that configuration should be able to contain functions, for example. The only possibility at the moment is to add a separate script file containing a MathJax configuration and to load it with. Describe the solution you'd like There are three possibilities: Allow arbitrary strings for mathjax3config, and in that case don't JSON-serialize them. Change to when loading MathJax. Make it possible for users to change to themselves. At the moment this isn't possible because the flags is unconditionally : The latter two are preferable because they would allow individual pages to use different MathJax config by using a block to override the default MathJax configuration on a given page (the script in that defer` option). CC , the author of . Thanks!


.. py:data:: :type: option does not correctly link to type supplied when using the .. py:data:: directive there is the :type: option to specify the type for the data being stored in the module level attribute. It does not work within the context of the module. What I mean by that is I have to key out the entire module path and the class for the type instead of importing the type into the module and only having to type in the type class name. say I have the following in the module "mylibrary.module1" The output I get when building the docs is this. and "Unit" is not a clickable link. However if I have the following in the module "mylibrary.module1" I get this for an output and "mylibrary.module2.Unit" is a clickable link that brings up the documentation for the Unit class to be able to do the following and have the output be and "Unit" be a clickable link that leads to the class that is specified in :type: No response Windows 8 2 No response No response


Different build warnings are colored differently Some types of warnings seem to be different colors than others. An image warning is light red, a transition warning is dark red. This behavior exists regardless of being set. Use the branch specified. I purposely broke an image's path to showcase the differently-colored warning so it's not on main or develop. Based on , I'd expect all warnings to have the same color, and to not match the color of errors. ! macOS 10.15.7 (Catalina) 7 Sphinx v4.1.2 No response No response No response


Using position-only parameter syntax in prevents docstrings for attributes from being parsed I'm currently using in most of my functions, including , however this prevents inline, before, and after doc strings from being parsed. Once is open, you will see that only has the property documented. Both classes should have the property documented <img width="636" alt="image" src="https://user-"macOS 11.6.1 10 1 , No response No response


Latex: terms are not separated by a newline I use simple indentations for terms and their explanation: Example: Which results in the following HTML output: Alabaster: ! RTD theme: ! While xelatex output does not contain a new line: ! Build the snippet. No response Build the snippet No response Linux 8 0 No response No response No response Latex: terms are not separated by a newline I use simple indentations for terms and their explanation: Example: Which results in the following HTML output: Alabaster: ! RTD theme: ! While xelatex output does not contain a new line: ! Build the snippet. No response Build the snippet No response Linux 8 0 No response No response No response LaTeX: glossary terms with common definition are rendered with too much vertical whitespace as in title and No response see code snippet ! Mac 0 2 Latex: terms are not separated by a newline I use simple indentations for terms and their explanation: Example: Which results in the following HTML output: Alabaster: ! RTD theme: ! While xelatex output does not contain a new line: ! Build the snippet. No response Build the snippet No response Linux 8 0 No response No response No response


fps should print as a formal power series When I first used , I didn't realize it really was a formal power series as it claims to be, because it prints like a normal series (same as ) But if you look at the string form, you see That is, it really does represent it as the formula (albiet, not simplified). It out to print it like this, so you can see that that's what it's working with. Side question: if you enter something it can't compute, it just returns the function Is that intentional? It seems like it ought to raise an exception in that case.


ccode(sinc(x)) doesn't work I don't think has , but it could print


diophantine: misclassification A check should be made that all powers are the same (not only that they are even).


distance calculation wrong The 3rd dimension is being ignored when the Points are zipped together to calculate the distance so is being computed instead of .


nsolve wrong result Here's a plot of the function in question. As you can see, the root should be around 0.7. !


ASCII printing for Singularity Function. Implementation of ASCII printing for Singularity Functions is needed.


Where oo belongs? (Concept) Hi again, well, i'm little confuse of the conditions to take or not in some sets: First the means the interval is created excluding and , and interval interpret it in that way, but now: Here is a little conflict, in first place Interval show don't take but now it is there? in some way is fine to have a way to can represent the from Interval. Now from this point we have some points: How they will interpret the limit concept? basically two options, limit is: or ? This point is very important, because define the behavior for sets, and affects directly like this issue: so, for now only to match the math in all sets we can say the limit is calculated via now, what is the effect of this in Sympy?, first this enable the limit concept in every unbounded set, for now i found this two issues: for example, actually we have this: this return should be something like... ? because in the limit we don't know what is the proportion of and , so we can't calc it. actually this concept is applied in some way like: Now the next question, will represent the infinite, as a integer, real or what? i know this question don't have sense, but let me try explain it: if the oo represent the infinite without form, it can exist in S.Naturals, and S.Reals, but if you represent the infinite like the interval between it, where is the limit of x to infinite while always , in other way where A go to and B do to , but it need always will respect this condition so between and can exist any type of numbers, so can't exist in because can contains a real number for example, but the extension of that concept says can't exist in any set, because always will exist a bigger set, in sympy you have an approximation of it, is , but don't will be true completely, because, why is it the limit set?, can represent two things, the limit of the actually human knowledge (or applied to Sympy), or the 'master' set, thinking its like the perfection of the sets knowledge. Obvs, to make some sense in the actual system the option is interpret without limit or form, and take the second interpretation of (if you take the first. can't exist in any place). If you disagree you always can discuss and change the behavior. Objetives of this issue: Get a clear definitions in Sympy of: Infinite Limit UniversalSet Then, clear the behavior of this concepts in Sympy, and to finish, set the behavior in Sympy. Thx. Cya.


Union(FiniteSet(oo), S.Complexes) gives S.Complexes (should remain unevaluated) Hi, well searching i found this: i don't know with this where belongs, is part of Complexes or not? Thx. Cya.


Exception when printing Symbol('') It has something to do with the unicode pretty printer. works.


set intersection gives TypeError: object of type 'Naturals0' has no len() This is from Optimistically marking this as easy to fix (I could be wrong).


lambdify precision loss with module=mpmath from high-precision Floats Floats with more than 16 digits are converted to double precision somewhere. Consider: Note has a 64-digit accurate Float in it (and the value is correct). But lambdifying and is not same: The help string for shows no loss: I haven't figured out how to look at the actual code yet, but somewhere something is being converted to double-precision (which might be fine for module=numpy but should not happen here).


simplifying exponential -trig identities Ideally, this would yield . Is there a way to do this? As a corollary, it would be awesome if could yield . Thank you for your consideration!


LaTeX printer inconsistent with pretty printer The LaTeX printer should always give the same output as the pretty printer, unless better output is possible from LaTeX. In some cases it is inconsistent. For instance: (I also don't think the assumptions should affect printing).


diophantine doesn't find solutions for 2x2+y2-16 Diophantine returns the empty set but and are solutions. I suspect there is some issue with the solving of the elliptic case, as for example also doesn't return all solutions: it returns and but fails to find and


evalf does not call imp recursively Example from The code for this is in . It isn't calling evalf recursively on the return of .


Dummy fails when is re-evaluated in S and srepr Hi all! Well, i found this little problem, Dummy is a nice function but in the way is implemented exist this: Basically, if you works with Dummy, and you get the expression with srepr or similar, when you eval it every Dummy will be interpreted as a new Dummy, so it fails, in the example you can see we can't eval the second expression because the 2 Dummy expression are interpreted as differents, other ex: So thinking a solution can be use a hash or similar function, like: Always will exist the hash collision, but at least to cover all possible can be sympy check the existents Dummy expressions and check the hash never by equal to other, the probability of the hash collision, to be equal, in the same context, with the same name, and in the same expression, i think is very low. Maybe instead use a hash can be a random expression, with chars like , that can help to avoid hash collision. Thx. Cya.


matematica code printer does not handle floats and derivatives correctly In its current state the mathematica code printer does not handle Derivative(func(vars), deriver) e.g. Derivative(f(t), t) yields Derivative(f(t), t) instead of D[f[t],t] Also floats with exponents are not handled correctly e.g. 1.0e-4 is not converted to 1.0^-4 This has an easy fix by adding the following lines to MCodePrinter: def printDerivative(self, expr): return "D[%s]" % (self.stringify(, ", ")) def printFloat(self, expr): res =str(expr) return res.replace('e','^')


Empty intersection should be UniversalSet It should be . See (settheory)#Nullary_intersection


List of prime factors including multiplicity is missing The vast majority of the time when using prime factorization in algorithms I'm interested in a list of prime factors. E.g. for 24 it's . However sympy (to my knowledge) only provides which returns a dictionary. I always end up writing a helper function: factorlist = lambda fac: sum(([p] * fac[p] for p in sorted(fac)), []) It would be really nice if factorizations in this format were directly provided by sympy, either by an option to (e.g. ) or under a new function name entirely.


b splines of degree 1? Looking at the spline_basis function: This seems to break while the following is fine: I can tweak in extra knots, i.e. placing them at (0.1,0.2, 10.1,10.2 in the example) but this is still not really giving the desired basis matrix. Or am I just missing something very obvious? I always generated knots for bspline basis matrix by taking the list of knots and:


Float constructor should allow to set binary precision I discussed this in some other issues, but I don't think I've opened an issue for it. The Float constructor only allows you to set the decimal precision. It then converts this to binary precision and saves that in . The problem here is that there are fewer decimal precisions than binary precisions. For example: So for instance, if you had a float that used 54 binary digits, it would be difficult to create a Float from it. I'm not even sure if it's possible, since in the current constructor, the argument overrides the fourth argument of a tuple input. One issue here is that everywhere else in the Sympy and mpmath code, refers to binary precision and refers to decimal precision. But currently, the second argument to is called , but refers to the decimal precision. So ideally, it should be where would override the default value of , and calling both (even consistently), like would be an error. Since the keyword argument name has to change, it would be a backwards compatibility break for anyone who calls Float like . Ideally this would require a deprecation cycle, but it's not possible to detect if someone is calling meaning the old way (20 decimal digits) or the new way (20 binary digits). The good news is that and call this argument , so there's no need to change things there.


cannot extract_multiplicatively(-2) from (-2x - 2y) I think this might be a bug. similarly: Assuming it is indeed a bug, here is why it happens: Look in where: which is then made into a non-evaluated , from which cannot be multiplicatively extracted; for example: do you think this is bug? (see your commit : not clear whether we still need this special case anyway)


Test failure in Travis I was able to reproduce this locally on a 64-bit system running Ubuntu 16.04. How to reproduce:


Codegen: sign function in Fortran The Fortran code generated by Sympy for the sign function is not a valid Fortran syntax. With Sympy 1.0 and Python 3.6: (The same behavior is obtained with .) The syntax of the sign function in Fortran is given . I guess it would be preferable to generate something like or depending of the context. I'm not sure how to get the same behavior than Sympy for , but at least it would be compilable.


Sum of the elements of an identity matrix is zero I think this is a bug. I created a matrix by M.T * M under an assumption that M is orthogonal. SymPy successfully recognized that the result is an identity matrix. I tested its identity-ness by element-wise, queries, and sum of the diagonal elements and received expected results. However, when I attempt to evaluate the total sum of the elements the result was 0 while 'n' is expected.


DiagonalMatrix[i, j] -0 Similar to , DiagonalMatrix references to position (i,j) give 0:


isupper() raises IndexError for tall matrices The function Matrix.isupper raises an IndexError for a 4x2 matrix of zeros. The code for isupper() is For a 4x2 matrix, isupper iterates over the indices: The attempt to index the (3,2) entry appears to be the source of the error.


constructor fails with non-disjoint cycles Calling raises a instead of constructing the identity permutation. If the cycles passed in are non-disjoint, they should be applied in left-to-right order and the resulting permutation should be returned. This should be easy to compute. I don't see a reason why non-disjoint cycles should be forbidden.


Totient of any non-integer number According to the Totient function definition on , the totient of non-integer numbers is not there. But in sympy: the value is returned, instead of an error.


diffgeom does not support multivector fields (0,m) well enough A limitation of the diffgeom package is that it does not provide support for fields higher than (0,m). TensorProduct, WedgeProduct, and others all assume inputs of differential form-fields, while mixed multivector fields make sense in some contexts (such as Poisson geometry). I'll work on implementing (n,m)-fields in the current code, where it makes sense.


Poly(x,x,y).free_symbols -{x, y} instead of just {x} No free symbols of generators that don't appear in the expression of the polynomial should appear in the set of free symbols.


Wrong/surprising result from noncommutative The following behavior in Sympy seems surprising: I would have expected this produces . The issue appears to be that uses fractional powers in the substitution. This then raises questions on what noncommutative symbols in Sympy actually mean mathematically. At least in my use cases for them, certainly does not imply . I would suggest something like the following:


Behavior of Matrix hstack and vstack changed in sympy 1.1 In sympy 1.0: returns Now, same in sympy 1.1: returns (0, 3) whereas: returns (1, 6)


decompose() function in intpoly returns a list of arbitrary order The decompose() function, with separate=True, returns , which is ordered arbitrarily. What is this used for? It should be sorted somehow, or returning a set (in which case, why not just use the returned dictionary and have the caller take the values). This is causing test failures for me after some changes to the core. CC


Exponent doesn't fully simplify Say I have code like this: The output is How do I simplify it to 0?


degree(multivariate) -degree of first generator When giving the degree function a multivariate expression, the default degree returned is for the first generator which is chosen canonically but arbitrarily. When the degree method of Poly is called, this is not so bad because one would/should know what the generators are. For the case of using the function, however, I believe it allows ambiguity to pass silently by not requiring the generator to be specified. Here, the return value depends on the symbols chosen


Mod(x2, x) is not (always) 0 When the base is not an integer, is not 0. The base is not tested to be an integer in Mod's eval logic: so but


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


Problem factoring trivial polynomial The factoring of w is incorrect - look at the order of x it is 10^-8 not 10^-4. Bug in simplify ? Hi, I'm running into issues where simplify comes up with incorrect results. sympy verion 1.0, python version 3.52, ubuntu 16.04. I've also verified the same with the Sympy online console (). The problem comes when trying to simplify a mass matrix for a simple 3-DOF robot: If I use the matrix above directly, I get correct results: which should be: If on the other hand, I simplify first I get an incorrect result: I was wondering if this is a bug with simplify, or am I doing something wrong? Thanks.


simplify doesn't do the last simplification step Note: I'm using Python 3.5.1 and sympy 0.7.6.1. Full script is attached in the .zip file: I've been using Sympy to compute Laplacian in different geometrical coordinates system. This usually creates extremelly long expressions and simplify usually does a great job. However, I've come against one particular case where simplify does most of the job but doesn't perform the ultimate simplification step. I've reduced the problem set getting rid of all of the Derivative terms. The initial expression is still huge (675 ops!): ! A first call to sucessfully reduces it to : ! Which is great (23 ops), but somehow frustrating as we can factorize it a little more. If I apply again, then I get the expression I wanted (7 ops): ! If simplify worked perfectly, shouldn't yield a different result from From my understanding of how simplify works, it successively tries different simplification strategies and compares them. In that case, the order of the different strategies matters. In my particular case, the strategy than eventually did the final factorisation step may have been called to early. I fixed that calling simplify again. We could fix it applying an optional recursive mode at the end of the simplify function: I can make the pull request if that helps.


Simplification fails to recognize sin expressed as exponentials The expression for has not been recognized, while expressions for and have.


periodicity(Abs(sin(x)),x) return 2pi periodicity(Abs(sin(x)),x) returns 2pi instead of pi periodicity(x 2, x) give recursion error and It fixes issue it will stop any relational Expression from entering into infinite recursion and return None It improves the periodicity of absolute trigonometric function issue


AccumBounds needs recreatable str/srepr The str and srepr should be recreatable. The pretty printer should be the only thing that prints the pretty form.


implement Piecewise rewriting for Min and Max This was mention in . I am just puttng this here as a separate issue.


Test failures on non-NumPy environment Following tests fail on where NumPy is not installed: Temporarily fixed by : Following doctest fails:


evalf with subs argument incorrectly evaluates expressions with floor returns instead of 20. (Python 3.6.1, SymPy 1.1.1). It seems that incorrect attribute is somehow attached to the result of , which is why 20 is then rounded to the nearest power of 2. Considering that works correctly, perhaps a fix would be to make pass its subs argument to first, i.e., act the same as Based on a


Eigenvalues of a 3 by 3 symbolic matrix are not found by .eigenvals throws Since the characteristic polynomial is cubic, it can be solved explicitly: returns three roots of the characteristic polynomial. I do not understand why these are not found by which returns (hence the failure of method). Declaring x as a real symbol does not help. Based on Stack Overflow post


UnboundLocalError in evalf I found this after changing the order of Mul args in Based on the code, I think the elif clauses that define reprec and imprec should have an . That appears to fix it, although I didn't try to debug to see why the arg order is mattering here.


bell(n).limit(n, oo) should be oo rather than bell(oo) should take the value infinity, but the current output is . As the Bell numbers represent the number of partitions of a set, it seems natural that should be able to be evaluated rather than be returned unevaluated. This issue is also in line with the recent fixes to the corresponding limit for the Fibonacci numbers and Lucas numbers. I'm new to Sympy, so I'd appreciate the opportunity to fix this bug myself if that's alright.


Python 2-3 pickle fails with float-containing expressions Dumping a pickled sympy expression containing a float in Python 2, then loading it in Python 3 generates an error. Here is a minimum working example, verified with sympy git commit (master at time of writing), Python 2.7 and Python 3.6: and the result:


.subs on coth(log(tan(x))) errors for certain integral values from sympy import * x = Symbol('x') e = coth(log(tan(x))) print(e.subs(x, 2)) ... File "C:\Users\E\Desktop\sympy-master\sympy\functions\elementary\", line 590, in eval if cotm is S.ComplexInfinity: NameError: name 'cotm' is not defined Fails for 2, 3, 5, 6, 8, 9, 11, 12, 13, 15, 18, ... etc.


Product(n + 1 / 2k, [k, 0, n-1]) is incorrect from sympy import from import n,k p = Product(n + 1 / 2k, [k, 0, n-1]).doit() print(simplify(p)) 2(n(-n + 1)/2) + nn print(p.subs(n,2)) 9/2 This is incorrect- for example, the product for is . The correct expression involves the .


randMatrix won't generatte symmetric sparse matrices When setting the percent parameter to anything else than 100, randMatrix fails to generate symmetric matrices. Consider the following examples: ' ' ' In [1]: import sympy In [2]: from sympy.matrices import randMatrix In [3]: randMatrix(3, symmetric=True, percent=1) Out[3]: Matrix([ [13, 61, 13], [59, 29, 59], [88, 13, 61]]) In [4]: randMatrix(3, symmetric=True, percent=50) Out[4]: Matrix([ [90, 60, 0], [ 0, 0, 0], [60, 59, 25]]) In [7]: randMatrix(3, symmetric=True, percent=99) Out[7]: Matrix([ [0, 0, 19], [0, 0, 0], [0, 0, 0]]) In [9]: randMatrix(3, symmetric=True, percent=0) Out[9]: Matrix([ [78, 78, 61], [68, 8, 61], [22, 68, 8]]) ' ' ' Also, the documentation says , but the behaviour is the opposite. Setting it to 100 (default) produces the expected behaviour. The problem happens with both the released version from pypi and git master.


Mod(Mod(x + 1, 2) + 1, 2) should simplify to Mod(x, 2) From Also, something like could be simplified. Recursively.


Undefined functions with number arguments should have is_number be False Original issue for : Original author:


Python code printer (pycode) should support Assignment There is a lookup on 'contract', either we should give it a default in the or we should make the code accessing use with a default.


Matrix.col_insert() no longer seems to work correctly. Example: The 3 x 3 identify matrix to the right of the columns of twos is shifted from the bottom three rows to the top three rows. Do you think this has to do with your matrix refactor?


Ordinal arithmetic It would be nice if SymPy would have provided ordinal arithmetic. That would require either definining a new object called , that will either inherit from or from (option 1), or new assumption(s) that will allow the current symbols to be ordinals. How can it work with assumptions? Roughly as follows: and arithmetic should be defined: addition, multiplication and exponentiation (all are not commutative in general), and some other useful methods, such as: relationals supporting ordinals cantor normal form prime ordinals (perhaps also with the assumption) limits of sequences of ordinals cardinals (related to ) some "known" ordinals such as omega, omega_1, ..., epsilon numbers, etc. you can find a python implementation of non-symbolic ordinal arithmetic. I can be up to the task of defining a symbolic variation, but I don't think I can implement it in SymPy.


coset_table doctest failure (Fatal Python error: Cannot recover from stack overflow.) See https://travis- Here is the test header


Multiplying an expression by a Poly does not evaluate when the expression is on the left side of the multiplication Tested in Python 3.4 64-bit and 3.6 64-bit Version: 1.1.2.dev0


Cannot simplify x + csch(sinc(1)) from sympy import * x = Symbol('x') print(simplify(x + csch(sinc(1)))) ... File "C:\Users\E\Desktop\sympy-master\sympy\simplify\", line 433, in f rv = fmap KeyError: sinc (I should have said: cannot apply the simplification function, since I'm not expecting any simplification to actually take place).


fix the dimension mismatches when using (dot) the dimension mismatched when using A.dot(B) where A is matrix B is 1 x m or n x 1 matrix before fixing it, if we used B as m x n matrix where n or m != 1 it gives a strange answer, but after fixing it raises error if m or n not equal 1


@ (matmul) should fail if one argument is not a matrix Right now () just copies , but it should actually only work if the multiplication is actually a matrix multiplication. This is also how NumPy works


latex() and mulsymbol The pretty-printing function accepts a kwarg that must be one of four choices. I would like to be able to supply my own choice which is not in the list. Specifically, I want the multiplication symbol to be (i.e., a thin space). This is what I mean Thin spaces are used by sympy to separate differentials from integrands in integrals. Is there a reason why the user cannot supply the of their choosing? Or are the 4 choices a historical artifact? I'm willing to attempt making a PR to allow to be arbitrary (and backwards-compatible) if such a PR would be considered.


No support for [{90^^\circ }] I have latex [{90^^\circ }], which means angle ninety degree, for example (cos(90 degree)) = 0, please add support for that? I appreate your reply.


integrate(1/(2-cos(theta)),(theta,0,pi)) Sympy produces NaN. Actually for integrate(1/(a-cos(theta)),(theta,0,pi)) for a 1 should be pi/sqrt((a-1)*(a+1)). So, the right answer should be pi/sqrt(3). However sympy seems to use the subtitution like t = tan(x/2) which is infinite when x = pi. When I try integrate(1/(2-cos(theta)),theta) , I get "sqrt(3)I(-log(tan(x/2) - sqrt(3)I/3) + log(tan(x/2) + sqrt(3)I/3))/3". Simplify() or trigsimp() doesn't work. And I don't understand why imaginary number appears.


Max & Min converting using SymPy Why many languages likes js and R cannot be converted from Max & Min? !


Add evaluation for polylog Original issue for : Original author: Why does the expansion of polylog(1, z) have exppolar(-Ipi)? I don't see a reason for exppolar here: To my understanding, and are exactly the same function for all purposes. They agree for <1 by their power series definition. Both are branched at 1 in the same way. The mpmath evaluation implements their branch cuts consistently: when z is real and greater than 1, the imaginary part of both functions is -pi. I tested the evaluation at thousands of random points, real and complex: both return the same values. SymPy also agrees they have the same derivative, which is z/(1-z): But with the current implementation of , it would seem that expandfunc changes the derivative of the function: returns which doesn't simplify to 0. In general, I think that having exppolar in expressions like is just not meaningful. The additional information contained in "polar" is the winding number of some path about 0. Here, because of + 1, this ends up being the winding number about 1, which is irrelevant because log is not branched at 1.


ODE incorrectly classified as Bernoulli A bug reported on returns . This is clearly due to only excluding f(x); it should also exclude x and dx.


Matrix determinant raises Invalid NaN comparison with particular symbolic entries from sympy import from import a f = lambda n: det(Matrix([[i + aj for i in range(n)] for j in range(n)])) f(1) 0 f(2) -a f(3) 2a(a + 2) + 2a(2a + 1) - 3a(2a + 2) f(4) 0 f(5) nan f(6) Traceback (most recent call last): File "<pyshell", line 1, in <modulef(6) File "<pyshell", line 1, in <lambdaf = lambda n: det(Matrix([[i + aj for i in range(n)] for j in range(n)])) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\expressions\", line 53, in det return Determinant(matexpr).doit() File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\expressions\", line 37, in doit return () File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 270, in evaldeterminant return () File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 416, in det return self.evaldetbareiss() File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 213, in evaldetbareiss return cancel(bareiss(self)) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 211, in bareiss return signbareiss(( - 1, - 1, entry), pivotval) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 211, in bareiss return signbareiss(( - 1, - 1, entry), pivotval) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 211, in bareiss return signbareiss(( - 1, - 1, entry), pivotval) [Previous line repeated 1 more times] File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 55, in new rows, cols, flatlist = cls.handlecreationinputs(args, kwargs) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 2041, in handlecreationinputs for j in range(cols)]) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 2041, in <listcompfor j in range(cols)]) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\matrices\", line 208, in entry cancel(ret) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\polys\", line 6423, in cancel f = factorterms(f, radical=True) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\core\", line 1193, in factorterms return do(expr) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\core\", line 1189, in do [do(a) for a in p.args]) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\core\", line 1189, in <listcomp*[do(a) for a in p.args]) File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\core\", line 1171, in do if all(a.ascoeffMul()[0] < 0 for a in listargs): File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\core\", line 1171, in <genexprif all(a.ascoeffMul()[0] < 0 for a in listargs): File "C:\Users\E\AppData\Local\Programs\Python\Python36\lib\site-packages\sympy\core\", line 323, in lt raise TypeError("Invalid NaN comparison") TypeError: Invalid NaN comparison Correct me if I'm wrong but isn't the Bareiss algorithm only valid for integer matrices, which cannot be assumed here?


(-x/4 - S(1)/12)x - 1 simplifies to an inequivalent expression from sympy import x = Symbol('x') e = (-x/4 - S(1)/12)x - 1 e (-x/4 - 1/12)x - 1 f = simplify(e) f 12(-x)(-12x + (-3x - 1)x) a = S(9)/5 simplify(e.subs(x,a)) -1 - 3215(1/5)2(2/5)/225 simplify(f.subs(x,a)) -1 - 32(-1)(4/5)60(1/5)/225 N(e.subs(x,a)) -1. N(f.subs(x,a)) -0. - 0.189590423018741I


max & min i found most language cannot be converted into max & min like octave,Fortran and others (js and R have been fix , thx ;) )


Issue with a substitution that leads to an undefined expression If b is substituted by a, r is undefined. It is possible to calculate the limit But whenever a subexpression of r is undefined, r itself is undefined.


Printing should use short representation of quantities. There is a test that explicitly expects that printing does not use but : Is there a reason behind this? I find it quite user-unfriendly to look at instead of . It would be very easy to change here: But then, the above test would fail. Is anyone emotionally attached to the current verbose display of units and quantities? Use abbreviated form of quantities when printing Currently, the abbreviation used in the definition of quantities, e.g. in the definition of , is hardly used anywhere. For example: returns: This PR modifies printing of quantities to use the abbreviation if one was provided. Example: now returns: NOTE: I changed an existing test that explicitly expected the non-abbreviated name to be printed. I just do not see the point of such behaviour, but I am happy to be educated otherwise.


Display of SeqFormula() The Jupyter rendering of this command backslash-escapes the brackets producing: Copying this output to a markdown cell this does not render properly. Whereas: does render just fine. So - sequence output should not backslash-escape square brackets, or, should instead render?


Evaluating powers of Powers of tensor product expressions are not possible to evaluate with either method nor the function. This is an example session showing the issue where and shows expected result for and respectively.


Generation of wrong octave code for imaginary number representation Hi, sympy generates code like which gives an error in Octave 4.0. Would it be better to substitute it with ?


() should output a Sum() object Currently, () outputs an evaluated summation instead of an unevaluated expression: For large n this takes a long time to compute. It seems like this should output an unevaluated sum and if the user wants to expand the sum they'd call on the result. It may not be worth deprecating this behavior, but maybe we need to have a method.


Inconsistency when simplifying (-a)x * a(-x), a a positive integer Compare: vs


Failed coercion of an expression with E and exp to a field element throws This is the same kind of an issue that dealt with, apparently there is more to be done.


product(1 - a2 / (n*pi)2, [n, 1, oo]) should not evaluate to 0 (if the product is evaluated the correct result is )


logcombine(log(3) - log(2)) does nothing Original issue for : Original author:


Integrate(1/(x2 + y2), x) returns a wrong result The correct result is . It seems similar to .


sympify(u"α") does not work Original issue for : Original author: Original owner:


pprint(x*DiracDelta(x, 1)) gives TypeError: unorderable types: NoneType() int() I bisected it to commit : CC


Typesetting of big-O symbol Currently typesetting of big-O symbol uses the ordinary 'O', we can use the typesetting as defined here .


Converting to LaTeX was converted to which is in some fields is log10(10) or log2(10). There is '\ln' in LaTeX and should be converted to it not to


The difference of MatrixSymbols prints as a sum with (-1) coefficient Internally, differences like a-b are represented as the sum of a with , but they are supposed to print like a-b. This does not happen with MatrixSymbols. I tried three printers: str, pretty, and latex: Output: Based on a


Sign of generator of an algebraic numberfield calls , but the implementation is defective as it does not change the minimal polynomial. I think this could be fixed in two ways: Add code to create the changed minimal polynomial. Ignore the sign and remove the code changing it. I am inclined to prefer the latter, simpler solution, but I would also like to hear other suggestions.


vectors break pretty printing Also, when it does print correctly, the baseline is wrong (it should be centered).


LaTeX printer does not use the same order of monomials as pretty and str When printing a Poly, the str and pretty printers use the logical order of monomials, from highest to lowest degrees. But latex printer does not.


Modular inverse for negative modulo and sign resolve SymPy assigns the same sign as . Mathematically, has range for , for . The former sign assignment is used in C/C++/Java built-in modulo operator as returns . The latter sign assignment is used in Python's built-in modulo operator as returns . SymPy does not find modular inverses for negative modulo (because of the check). Moreover, as checked from WA (uses the same sign as rule)


Poly(domain='RR[y,z]') doesn't work Also, the wording of error message could be improved


ambiguous behavior of ConditionSet Does that mean the "set of all x in S for which condition(x) is True" or "the set S if the condition(x) is True"? Also, should there be a doit method or autoevaluation for something like this? Other fixes: should be S.EmptySet should be unchanged: the dummy is not there to help with the condition, only to test idientify where the element from the base_set should be tested in the condition.


Incorrect binomial documentation The for states: This is the usual definition of the binomial coefficient, but the implementation does not follow this. To be exact, returns , even for negative . See . For example: ` It shouldn't be hard to fix this either way (changing the documentation or the conditionals in ). Is there a preference as to which one should change?


binomial(n,n) needs simplify to become 1 After , does not become 1. Sure. But even with appropriate assumptions, we need to simplify: was that intentional? Maybe its not important given that DTRT with ... Thoughts?


orientnew in sympy.physics.mechanics does not support indices Original issue for : Original author:


Latex printer does not support full inverse trig function names for acsc and asec For example works as expected returning But gives instead of A fix seems to be to change line 743 of from to


Error pretty printing MatAdd The code shouldn't be using sympify to handle string arguments from MatrixSymbol. I don't even understand what the code is doing. Why does it omit the when the first argument is negative? This seems to assume that the arguments of MatAdd have a certain form, and that they will always print a certain way if they are negative.


lambdify(modules='mpmath') doesn't wrap rationals This results in reduced precision results from , because the 232/3 isn't evaluated at full precision. Originally reported at


lambdify does not work with certain MatrixSymbol names even with dummify=True is happy with curly braces in a symbol name and with s, but not with both at the same time, even if is . Here is some basic code that gives the error. The following two lines of code work: The following two lines of code give a :


of rank-0 arrays returns 0 always returns zero for rank-0 arrays (scalars). I believe the correct value should be one, which is the number of elements of the iterator and the observed behaviour in numpy. In numpy we have the following: This was tested in sympy 1.2-rc1 running in Python 3.6.6 of rank-0 arrays returns 0 always returns zero for rank-0 arrays (scalars). I believe the correct value should be one, which is the number of elements of the iterator and the observed behaviour in numpy. In numpy we have the following: This was tested in sympy 1.2-rc1 running in Python 3.6.6


[regression] lambdify with Matrix: I'm trying to create a lambda function from a sympy expression that involves a dot product with a . Since at least sympy 1.2, this fails. MWE: Error message:


not pretty printing indexed(x1, i) not sure if this is expected behavior but i'm expecting x_{1,i} !


xor boolmap equivalent to xnor? - Flaw in finger fingerprint results in The simplified functions fro f1 and f2 are correct, and clearly different, yet bool_map returned what it though to be a valid symbol mapping?


autowrap fortran fails with expression containing Mod function twice Minimal example: Error: And here's the generated code. Clearly the problem is that Mod gets imported twice. Hopefully this is an easy fix but I don't know where to start.


factor() function issue for non-commutative objects In commit by from line 652 to line 660 in the file , there are some parts that I couldn't understand: I am trying to add a non-commutative class whose freesymbols are commutative. (e.g., operator with time dependence) In this case, even if the object itself is non-commutative, the factor() function gives the wrong result, because of the lines In my understanding, this line treats a non-commutative object as commutative if all its freesymbols are commutative. What is the purpose of this line?


better canonicalization of variables of Derivative Better canonicalization of will be had if any symbols, appearing after functions, that are not in the free symbols of the function, appear before the functions: should equal .


recognize elliptical integrals Original issue for : Original author: Added function for finding equation of Ellipse using slope as parameter and faster method for calculation of circumference of ellipse Added function for finding equation of Ellipse using slope as parameter. Added another method for calculation of circumference of ellipse. Added a new method called Pluralized the following methods -- This PR uses the approach to finding equation of ellipse using slope, length of semi minor axis and length of semi major axis as inputs given This could be an functionality to the equation finding method in class . Thanks to for providing the approach. Please take a look at this PR and suggest changes. I will be glad to implement them. Thanks. <!-- BEGIN RELEASE NOTES --geometry function for finding equation of Ellipse using slope as parameter <!-- END RELEASE NOTES --


Problem with Beam module I think there is a problem with the Beam module when using a force with an order bigger than 1. This is an example where R should be 1/3 and remains constant when changing the length of the beam, but unfortunately it's not the case. I believe it has to do with the formation of the load equation, where the higher order compensation isn't been taken into consideration. !


LaTeX printing for Matrix Expression The bad part is not only is Trace not recognized, but whatever printer is being used doesn't fallback to the LaTeX printer for the inner expression (it should be ).


RootOf might ignore generator This is related to but a little different. I'm not sure of all the ramifications but just want to document this. Note how feeding RootOf an expression in terms of a new generator might ignore that generator if the form of the polynomial is the same


mathematica_code gives wrong output with Max If I run the code then I would expect the output which is valid Mathematica code but instead I get which is not valid Mathematica code.


can't simplify sin/cos with Rational? latest cloned sympy, python 3 on windows firstly, cos, sin with symbols can be simplified; rational number can be simplified says but says


Incorrect result with Quaterniont.torotationmatrix() There appears to be an error in the output. The simplest example I created to illustrate the problem is as follows: One of the functions should be negative. What was the reference of the original equations?


LaTeX printer omits necessary parentheses in matrix products such as x(-y) The product of x and -y, where x, y are MatrixSymbols, is printed as by the LaTeX printer: Source: on Stack Overflow.


Python 3.7 test failures Running tests from master under Python 3.7.1 (which isn't tested on Travis) I see some failures. The fastest ones to see are from but there is another in . I'm not sure what has changed in 3.7 to cause this. The error from is


Should Point.distance(Line) return distance? In Geometry module, can be used to compute distance, but cannot. Should this be made symmetric?


SymPy's doesn't agree with the builtin divmod Both are mathematically correct according to the invariant in the docstring, , but we should be consistent with Python. In general in Python, the sign of mod should be the same as the sign of the second argument. Our is already correct, so it's just that needs to be corrected


Can't get an inverted float matrix with sympy and numpy Trying to get an inverted matrix with sympy and numpy. lambify fails with the following message:


The behavior of degree(f, x) on rational functions I wanted to know if SymPy can compute degrees of rational functions, so I tried Perhaps the degree of a rational function is not implemented, but if so, should this fail instead?


Mod(3i, 2) unchanged should reduce to (as reported in ) and will do so with a change something like this: Returns correct result to Mod(3i, 2). modified the to return correct answer to Mod(3i, 2). a test (All as suggested by ) Earlier sympify(3k%2) Mod(3k,2) Now sympify(3k%2) Mod(k,2) Release Notes <!-- BEGIN RELEASE NOTES --functions fixed a bug in mod a test <!-- END RELEASE NOTES --


Indexed matrix-expression LaTeX printer is not compilable The LaTeX string produced by the last command is: LaTeX complains about a double subscript . This expression won't render in MathJax either.


Sets printing issues Some issues with str and srepr printing in sets. Some notes: The printer should always generate valid Python, which recreates the expression (but may require some variables to be defined). The printer should generate an expression that recreates the expression exactly, using only the names from (or other relevant imports for other submodules, but that isn't relevant for the sets). Fancy printing should be relegated to the pretty printers ( and ). Here are the issues I found: The former creates a list, not an interval. The latter isn't even valid Python. (and probably others) isn't a name that is imported from . It should print as . The printers should probably do the same. It's not valid Python. It should print as . Printing as is fine when gets merged. There are likely others. I didn't check too much. An audit of the printing in the sets module would be worthwhile.


Some issues with idiff idiff doesn't support Eq, and it also doesn't support f(x) instead of y. Both should be easy to correct.


Make .scalefactor private in the units module sympy version: 1.3 Python version: 3.6.6 Operating System: Win10 Dividing a Quantity with dimension voltage by a Quantity with dimension current yields ohm/1000 when I expected ohm. In the SI system, 1 V/ 1 A = 1 Ω. The problem is related to the kilogram workaround and the property . The default scalefactor for a Quantity is 1. The docstring for `scalefactor' states: But, the scale factor for ohm is 1000. ohm.scalefactor 1000 This value of 1000 conflicts with the definition. is a user facing property and should be consistent with the unit system definition, in this case the SI. The kilogram workaround should be an internal implementation factor and not exposed to the user.


Zero-argument Min() and Max() Right now and with no arguments raise . It might be mathematically more convenient to have them return and , respectively. See for why these are valid answers mathematically.


iszero is incorrect on complex integer should return if it cannot decide, but should never give the wrong answer. However: This is causing errors in determining the rank of a matrix. See issue Fixing iszero for complex numbers while Add References to other Issues or PRs Other comments: <!-- BEGIN RELEASE NOTES --- core Fix becoming on some expressions with . <!-- END RELEASE NOTES --


Wrong measurement for one qubit state. Hi, sympy developers. measure_all(qapply(Qubit('0'))) returns [(0, 1)] best, Vladimir.


Use '\ ' instead of '\quad' for latex of lists, tuples, and dicts See Twitter discussion.


Add pretty printing functionality for lerchphi fuction <!-- 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 .--Added functionality to pretty print lerchphi function in Fixes the lerchphi part of . <!-- Write the release notes for this release below. See for more information on how to write release notes. If there is no release notes entry for this PR, write "NO ENTRY". The bot will check your release notes automatically to see if they are formatted correctly. --<!-- BEGIN RELEASE NOTES --NO ENTRY <!-- END RELEASE NOTES --


A symbol ending with a number is made invisible when printing with MathML A variable with a number, such as x1, is made invisible when printing in a MathML format. import sympy from import mathml x2, y, z = sympy.symbols('x2 y z') y = x2z+x23 f = open('', 'w') f.write('\n') f.write('\n') f.write('\n') f.write('\n') f.write((y, printer='presentation')+'\n') f.write('\n') f.write('\n') f.write('\n') f.close() Viewing the output in Safari 12.0.2: <img width="93" alt="screen shot 2018-12-31 at 12 21 00 pm" src="https://user-"If 'x' is used instead of 'x2', it works as expected: x, y, z = sympy.symbols('x y z') y = xz+x3 <img width="78" alt="screen shot 2018-12-31 at 12 26 24 pm" src="https://user-"BTW, I'm on a MacBook Pro, OS 10.14.2, Sympy 1.3, in Eclipse 2018-19, and Python 3.7.


MathML presentation printing of multiple derivatives messed up Currently, the MathML presentation printed version of the expression looks like: ! while a proper rending would be more along the lines of the LaTeX equivalent: ! Hence, the method should be improved, first and foremost to print all the derivative variables on a single line and to get the correct power in the numerator. It is also preferred if the actual function ends up on a separate line (not sure if there is some logic to tell when this should or should not happen). If possible, the logic to group adjacent identical terms can be applied, see the discussion and code in which gives an idea of how to implement it. [To be closed] Added printderivative2 methods from <!-- 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 . Please also write a comment on that issue linking back to this pull request once it is open. -- As the attached diff in was pretty large due to line endings, I extracted the interesting parts, the methods for LaTex, pretty and MathML printers. Not sure what to do with it. It looked quite promising in the original PR. Maybe one should have a switch to select between these two methods of printing? I have not checked the code more than modifying it to work with current Python and sympy version, at least from a "no-static-warnings-in-Spyder"-perspective. <!-- 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 --NO ENTRY <!-- END RELEASE NOTES --MathML presentation printing of multiple derivatives messed up Currently, the MathML presentation printed version of the expression looks like: ! while a proper rending would be more along the lines of the LaTeX equivalent: ! Hence, the method should be improved, first and foremost to print all the derivative variables on a single line and to get the correct power in the numerator. It is also preferred if the actual function ends up on a separate line (not sure if there is some logic to tell when this should or should not happen). If possible, the logic to group adjacent identical terms can be applied, see the discussion and code in which gives an idea of how to implement it.


Fix Matrix Equality and MatrixExpr <!-- 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 . Please also write a comment on that issue linking back to this pull request once it is open. --Test case for equality in matrices. <!-- 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 test for equality in matrices <!-- END RELEASE NOTES --


Make assumptions about indexed symbols I think this should be possible to do: Without assumptions, it's hard to do algebra with indexed symbols, e.g., get to simplify to . I understand that the class Indexed inherits from Expr, not from Symbol, and there are no assumptions on Expr. Still, we already have some quasi-assumptions on Indexed and IndexedBase in the form of class property. And the objects of class Idx, which also inherits from Expr, have them in the form as . Could parse and use the that it accepts, instead of trying to pass them to ? Optionally, maybe even could do that, so an assumption can be to a particular indexed object? By the way, any attempt to pass to is a potential bug because this method, inherited from , does not accept any keyword arguments.


mathml printer for IndexedBase required Writing an object to MathML fails with a exception: : It also fails for more complex expressions where at least one element is Indexed.


Mathematica code: allow printing of matrices and arrays. Our printers for Wolfram Mathematica do not support matrices and arrays. We should add support for it.


Product pretty print could be improved This is what the pretty printing for looks like: (if those don't look good in your browser copy paste them into the terminal) This could be improved: Why is there always an empty line at the bottom of the ∏? Keeping everything below the horizontal line is good, but the bottom looks asymmetric, and it makes the ∏ bigger than it needs to be. The ∏ is too fat IMO. It might look better if we extended the top bar. I'm unsure about this. Compare this That's still almost twice as wide as the equivalent Sum, but if you make it much skinnier it starts to look bad.


Issue ufuncifying a two argument function with the Cython backend It works if the function just has one argument, or if you use a different backend. Issue ufuncifying a two argument function with the Cython backend It works if the function just has one argument, or if you use a different backend.


S(0)real(!=0) should be (0 or zoo) and hence non-positive. Consider the following code from master: Since (where a is real and non-zero) should always be (0 or ). Therefore, the result should have been .


latex printing of BaseScalar It appears that the subscript and script are reversed here for the latex form of BaseScalar:


Float from string with underscores misplaces decimal point This is correct: None of these are: I think this is an upstream bug in mpmath:


Posify ignores is_finite assmptions Posify removes a finite assumption from a symbol: I think that posify should preserve the finiteness assumption. Possibly other assumptions should be preserved as well (integer, rational, prime, even, odd...).


Add LaTeX and pretty printers for HadamardPower Furthermore, HadamardProduct may be extended to support the division symbol. [ ] Add latex printer [ ] Add mathml printer [ ] Add pretty printer


Bad centering for Sum pretty print The and the should be aligned. I'm not sure if the should be lower of if the should be higher.


collectconst() does cannot collect rationals does not seem to support the collecting of numeric rationals in SymPy 1.3. This is probably a duplicate of , but I've provided a description below. In [41]: var('a:d') In [42]: f = a + b + c / 2 + d / 2 In [43]: print(collect_const(f, Rational(1, 2), Numbers=True)) a + b + (c/2 + d/2) I'm expecting


parsing expressions with powers from sympy.parsing.sympyparser import ( parseexpr, standardtransformations, implicitmultiplicationapplication, ) and if i will do something with expr1 and expr2 i will get wrong results: print(expr1 - expr2) --6n - 3n*2n # Not Zero!!! i have tried simplify, powsimp (force=True too), powdenest, also i have tried create var('n', positive=True, integer=True) and set parameter localdict into parseexpr and use another transformations in parsing, but i could not get 0. Maybe somebody tell me how i can get zero after expr1 - expr2? Thank you


Intersection between Plane and Segment3D returns points outside of the segment It seems to me that, as far as ), and so additional intersections that aren't actually within the segment are returned: The expected result is of course that returns an empty list in this case. An easy workaround for the time being is to just filter these out manually: But it would be nice if this could be fixed in sympy itself. Version info: Python 3.5.3 Sympy 1.2-522-g0b350a21a () Updated intersection method in class Plane Updated the isinstance(o, (LinearEntity, LinearEntity3D)) part of intersection method in Plane class so that the returned points lie in both the intersection objects. <!-- BEGIN RELEASE NOTES --geometry updated the intersection method of plane class so that intersection points lie in both the intersection objects if the other entity is LinearEntity. <!-- END RELEASE NOTES --


PythonCodePrinter doesn't support Indexed I use to generate some functions and save the code for further use. But the generated code for operation has some warnings which can be confirmed by following code; the output is We should add following method to :


dotprint doesn't use the correct order for x2 The dot diagram in the tutorial is wrong (). It shows but it should show since it represents , not . I can't figure out how to make dot give the vertices in the right order. Whatever the fix is, we should fix this in the dot printer as well as the tutorial.


autowrap with cython backend fails when array arguments do not appear in wrapped expr When using the cython backend for autowrap, it appears that the code is not correctly generated when the function in question has array arguments that do not appear in the final expression. A minimal counterexample is: This should of course return but instead fails with: A little inspection reveals that this is because the corresponding C function is generated with an incorrect signature: ( should be , not in this case) I've found that this error won't occur so long as depends at least in part on each argument. For example this slight modification of the above counterexample works perfectly: This may seem like a silly issue ("why even have as an argument if it doesn't appear in the expression you're trying to evaluate?"). But of course in interfacing with external libraries (e.g. for numerical integration), one often needs functions to have a pre-defined signature regardless of whether a given argument contributes to the output. I think I've identified the problem in and will suggest a PR shortly.


Bug in ImageSet I think we should not use . Reason : It works fine when returns a non-empty set. But when it returns an empty set, an error is raised. As calling on an empty set raises an . This is most likely the reason why this is failing for and passing for Also, why are we type-casting the to a ? Ping Maybe you can help me out here.


Morse encoding for "1" is not correct The current Morse mapping in contains an incorrect mapping of The correct mapping is .


Added OneMatrix str, pretty, and MathML presentation printing


doesn't always return a formal power series See the following: I assume the logic is that the value in question is already a polynomial so doesn't need expansion, but it doesn't support the same interface, and doesn't suggest that this is what is supposed to happen. fix issue


Intersection should remove duplicates The answer should be or remain unevaluated. The routine should give the same answer if duplicates are present; my initial guess is that duplicates should just be removed at the outset of instantiation. Ordering them will produce canonical processing.


Some uses of couldextractminussign can lead to infinite recursion The issue coming from was fixed, but there is another issue has come up in my pull request Several places in use couldextractminussign() in a way that can lead to infinite recursion. For example, in : The problem is that both and could be True, leading to infinite recursion. This happens in my branch for , but probably an example could be found for master too. We need a more robust way to canonicalize this. Ideally we'd want to remove the minus sign from the highest order term. Is there a fast way to do that?


Lambdify misinterprets some matrix expressions Using lambdify on an expression containing an identity matrix gives us an unexpected result: Instead, the output should be , since we're adding an identity matrix to the array. Inspecting the globals and source code of shows us why we get the result: The code printer prints , which is currently being interpreted as a Python built-in complex number. The printer should support printing identity matrices, and signal an error for unsupported expressions that might be misinterpreted.


isqrt gives incorrect results The function in gives incorrect results for some inputs. For example: or Versions: Python 3.7.3, SymPy 1.4, macOS 10.14.5 For small values of , the uses (aliased to ): The main problem is that the bound used for here is much too large, at almost . If (and it's quite a big if) we can assume that Python floats are IEEE 754 binary64 format and that supplies a correctly-rounded (using round-ties-to-even) square root function, then the largest bound that can safely be used here is , or . If we can assume IEEE 754 binary64 s but can't assume a correctly-rounded , then is still safe for smallish , where the definition of "smallish" depends on how accurate is. For example, if is known to be accurate to within 2 ulps, then it's possible to show that is safe for . (The is necessary here: wouldn't be safe even for tiny , since e.g. if the result of is off by a single ulp downwards, would produce instead of .) Whether is correctly rounded or not will depend on the platform: Python's just wraps the function from C's math library. On modern x64 hardware, one would expect and hope that C's gets mapped to the appropriate SSE2 instruction, in which case it'll be correctly rounded. But on ARM there may well not be a hardware sqrt instruction to map to, and a hand-implemented libm sqrt could easily be incorrectly rounded for some inputs. In the unlikely (but possible) case of non-IEEE 754 binary64 s, it's probably safer to avoid using at all. But this case is likely to be exceedingly rare, and doesn't seem worth worrying about in practice. I guess one option for fixing this while retaining performance for small would be to continue to use the code, but then to check the result is correct before returning it, falling back to the slow integer-only path if that check doesn't pass.


Simplify returns incorrect result with trig functions %0A%23--%0Aexpr%20%3D%20(-sin(beta%2F2)sin(alpha%2F2%20-%20gamma%2F2)sin(alpha%2F2%20%2B%20gamma%2F2)%2F(2cos(beta%2F2)cos(alpha%2F2%20%2B%20gamma%2F2)2)%20%2B%20sin(beta%2F2)cos(alpha%2F2%20-%20gamma%2F2)%2F(2cos(beta%2F2)cos(alpha%2F2%20%2B%20gamma%2F2)))%2F(sin(alpha%2F2%20%2B%20gamma%2F2)2%2Fcos(alpha%2F2%20%2B%20gamma%2F2)2%20%2B%201)%20%2B%20(sin(alpha%2F2%20-%20gamma%2F2)sin(alpha%2F2%20%2B%20gamma%2F2)cos(beta%2F2)%2F(2sin(beta%2F2)cos(alpha%2F2%20-%20gamma%2F2)2)%20-%20cos(beta%2F2)cos(alpha%2F2%20%2B%20gamma%2F2)%2F(2sin(beta%2F2)cos(alpha%2F2%20-%20gamma%2F2)))%2F(sin(alpha%2F2%20-%20gamma%2F2)2%2Fcos(alpha%2F2%20-%20gamma%2F2)2%20%2B%201)%0A%23--%0Aprint(mathematicacode(expr))%0A%23--%0A%23%20Using%20Mathematica%20to%20Simplify%20that%20output%20results%20in%20-Cos%5Balpha%5DCot%5Bbeta%5D%0A%23--%0A%23%20That%20is%20also%20the%20result%20that%20one%20can%20get%20using%20basic%20trig%20identities%0A%23--%0Aexpr%0A%23--%0Asimplify(expr)%0A%23--%0A%23%20That%20is%20the%20incorrect%20result%0A%23--%0A]) shows an incorrect result when applying to a fairly large (but ultimately basic) expression involving lots of trig functions. I get the same result on version 1.4 on my own computer, and was getting this result from 1.3 before I updated today. EDIT: Note that Ethan reduced this to a much simpler expression below, so that's obviously a better MWE. I'm sorry that I haven't been able to cut it down to smaller size and still get an error; I have tried. The MWE is this: The output is [which could be further simplified to ]. It should be as verified by Mathematica (directly using the output of ), and by direct calculation using trig identities. This isn't just a matter of refusing to do something that may not always be true; this is really the wrong result. The expression looks big and ugly, but is actually pretty simple when you stare at it for a minute: <img width="802" alt="Screen Shot 2019-06-20 at 2 11 30 PM" src="https://user-"Those denominators can be simplified immediately to of the respective arguments. Then you just cancel, group terms, and apply standard trig identities, and get the correct result. Sympy will actually correctly simplify each fraction individually, but then it refuses to further simplify the sum — but at least that sum would be correct, unlike what it does with this whole expression. (Of course, this happened in the middle of a much longer calculation, so I didn't know it was going wrong, and have spent the past few days wondering why I was getting inconsistent results when using this wrong answer.)


Piecewise doesn't works correctly <!-- The title above should be a short description of the issue. --Code Result It's not working on as well, see the screenshot below, ! [1] told that it is working fine on their systems. Please help me out, either we should fix it or please suggest an alternative approach. I suspect that the error is caused, due to in . May be at least should be allowed to pass through the following loop,


simplify(cos(x)**I): Invalid comparison of complex I ()


Incorrect extraction of base powers in log class Evaluating produces , but it should produce . The issue seems to originate around line in during extraction of base powers, where is evaluated to but should evaluate to : if den.isInteger: return n + log(arg // den) / log(base) else: return n + log(arg / den) / log(base) I would suggest to fix the issue by removing the conditional and keeping the else branch (seems like a case of premature optimization). Alternatively, this also seems to fix the issue: if arg.isInteger and den.is_Integer: return n + log(arg // den) / log(base) else: return n + log(arg / den) / log(base) That said, seeing that this code was not changed recently, the issue may run deeper.


Automatic evaluation of RisingFactorial(n, k) with n negative integer, k non-integer This could be evaluated automatically. Note that this causes problems when used in larger expressions, for example:


xor3 boolmap equivalent to xnr3 Extension of Results in: Also due to a flaw in the finger fingerprint routine: Results in an identical fingerprint: This is also broken for XOR4 and XNR4. I haven't tested for more inputs beyond 4


Piecewise simplification (to avoid doit growth) Perhaps that situation should be recognized during instantiation. Or else might need to call first to avoid repeating what is known (as was reported ):


printingMathML erroneous I believe I found some mathML printing errors, and noted below what I think it should be should be: should be: should be:


Match doesn't respect matrix non-commutativity doesn't obey the commutativity of matrix expressions when matching scalars between two expressions. As a demonstration: should be , since the associated matrix multiplications are in a different order (and so not indentical).


exp doesn't simplify based on its periodicity In current master, doesn't use its periodicity to automatically reduce its argument, not even for purely imaginary arguments:


frac(zoo) gives TypeError Not sure what should happen, but not this. I am trying to cover these lines in a test: Clearly, they are covered by calling since the comes from that line, but I do not really want an exception...


Incorrect value for hbar in The numerical value given for hbar differs from the CODATA recommended one of: .


Latex printing issue on derivatives with superscripted symbols When I display the derivatives of second-or-more order with superscipted symbols, it gives wrong latex expression and fails to print correctly with IPython environment. For example, this gives instead of nice latex formula. I figure that this is because x^{}^{2} is wrong latex expression. It should be x^{2}, and thus I report it as an issue.


ceiling(pos) 0 should be true Also, shouldn't , and evaluate to True, too?


sqrtdenest raises IndexError If an expression cannot be denested it should be returned unchanged. IndexError fixed for sqrtdenest. Now if the expression can't be denested, it will be returned unchanged. Old Result: New Result:


Permutation args are now subtypes of Basic Permutation has currently a subtype in its args. I changed that to


Exception when multiplying BlockMatrix containing ZeroMatrix blocks When a block matrix with zero blocks is defined then block-multiplying it once seems to work fine: but block-multiplying twice throws an exception: This seems to be caused by the fact that the zeros in are not but : However, I don't understand SymPy internals well enough to find out why this happens. I use Python 3.7.4 and sympy 1.4 (installed with pip).


new of IndexedBase upcasts subclass of Symbol to Symbol First, thanks for creating SymPy. We're using it in a code generation framework: We noticed that our tests are failling when using the current master of SymPy. To reproduce run: While should work fine. The reason for this failure seems to be in the call of the constructor of . We're a calling it with a subclass of () which is essentially a sympy Symbol with type information. Is there a reason why the out-commented line is necessary? It causes our TypeSymbol to lose its type information by re-constructing a new Symbol. When I out-comment this line everything works fine again. In new of IndexedBase upcasts subclass of Symbol to Symbol First, thanks for creating SymPy. We're using it in a code generation framework: We noticed that our tests are failling when using the current master of SymPy. To reproduce run: While should work fine. The reason for this failure seems to be in the call of the constructor of . We're a calling it with a subclass of () which is essentially a sympy Symbol with type information. Is there a reason why the out-commented line is necessary? It causes our TypeSymbol to lose its type information by re-constructing a new Symbol. When I out-comment this line everything works fine again. In


Unexpected exception when multiplying geometry.Point and number This line works fine But when I write the same this way it raises an exception The expected behaviour is, that both lines give the same result


Refine with sign Consider the following code: All the returned expression are . However, at least for and , the results should be . This probably is due to the lack of capabilities for . A PR similar to should fix this behaviour. Related issues: and .


sqrt(sympify('')) gives wrong answer It is easily verified that this answer is not correct; notably:


Corrected functions in subclasses of Corrected the and functions. These functions are still sort of incomplete (couldn't think of all cases, any improvements are welcome). They can directly be used to define properties like and for , , and .


Modified ispositive for cosh function returns if x is real. Also modified the function to return the function itself or its negative if the function is positive or negative. Example: abs(cosh(x)) should simplify to cosh(x) for real x Sympy 1.0 only simplifies in a limited set of cases:


Intersection of ImageSet gives incorrect answer. After git bisecting by this has changed the output of ping -


Catalan rewrite and doctests for latex equations First, implement . Also, something I've been thinking about for while: we have lots of LaTeX in our docs. In many cases we could generate those equations ourselves instead of typing them manually (I found errors while doing for example). This PR should demonstrate the idea. what do you think? Will this work? Its certainly nice for maintainance, although it is probably slightly less readable... (If we want to do this widely, the latex printer could probably be optimized for things like and when it uses instead of .) <!-- BEGIN RELEASE NOTES --core Catalan can be rewritten as a sum <!-- END RELEASE NOTES --


interpolate could provide value instead of nan Since the default x value for interpolation is the interpolation at 5 could just return 115 instead of nan.


Sympy incorrectly attempts to eval reprs in its eq method Passing strings produced by unknown objects into eval is very bad. It is especially surprising for an equality check to trigger that kind of behavior. This should be fixed ASAP. Repro code: Results in: On the line: Where code is: Full trace: Related issue: an unknown object whose repr is will incorrectly compare as equal to a sympy symbol x:


imageset broken for complex numbers With current master: The (or any other value) is simply dropped.


Simplify of simple trig expression fails trigsimp in various versions, including 1.5, incorrectly simplifies cos(x)+sqrt(sin(x)**2) as though it were cos(x)+sin(x) for general complex x. (Oddly it gets this right if x is real.) Embarrassingly I found this by accident while writing sympy-based teaching material...


Why pretty print of "oo - oo" has result "nan", if the evaluation is disabled?


ImageSet of n**2-1 returns EmptySet as intersection with Integers (diophantine bug)


Range(1).intersect(FiniteSet(n)) raises TypeError: cannot determine truth value of Relational


Are of 's properties valid? currently, there properties aren't initialized . if there properties are thought wheather Q(S.Rationals) is open or closed set in R (S.Reals), should return and . if use there properties as undefined, should return a exception ? Are of 's properties valid? currently, there properties aren't initialized . if there properties are thought wheather Q(S.Rationals) is open or closed set in R (S.Reals), should return and . if use there properties as undefined, should return a exception ?


diophantine: incomplete results depending on syms order with permute=True diophantine: incomplete results depending on syms order with permute=True


Recursion error: sqrt(1 / tan(1 + I)) There should be an additional check on this line:


nthrootmod function misses one root of x = 0 mod p. When in the equation x*n = a mod p , when a % p == 0. Then x = 0 mod p is also a root of this equation. But right now does not check for this condition. has a root . But it does not return it.


ImageSet(Lambda(n, n**2), S.Integers).intersect(S.Integers) raises AttributeError This is in the related intersection code. See also: , and


raises instead of returning The problem is Here raises but probably a should be returned by instead. The obvious result of here is Originally posted by in


Un-parenthesize superscripted symbol Let's think of these superscripted symbols, x^{i}, x^{} <img src="^{i},&space;x^{}" title="x^{i}, x^{}" /Currently, SymPy parenthesizes these symbols when they are taken to power: \left(x^{i}\right)^{2}, \left(x^{}\right)^{2} <img src="\left(x^{i}\right)^{2},&space;\left(x^{}\right)^{2}" title="\left(x^{i}\right)^{2}, \left(x^{}\right)^{2}" /However, LaTeX has its own way to represent these symbols without parentheses by nesting them: {x^{i}}^{2}, {x^{}}^{2} <img src="{x^{i}}^{2},&space;{x^{}}^{2}" title="{x^{i}}^{2}, {x^{}}^{2}" /These are distinguised from 'powered superscription's, which are: x^{i^{2}}, x^{\^{2}} <img src="^{i^{2}},&space;x^{^{2}}" title="x^{i^{2}}, x^{^{2}}" /Then, shouldn't it be better to print them without parentheses? As far as I know, that is the conventional way to print power of superscripted symbols. In , you can see that nabla sign is superscripted then powered without any parenthesis: {\nabla^{}}^{2} <img src="{\nabla^{}}^{2}" title="{\nabla^{*}}^{2}" /


[WIP] Additional matrix support for NumPy printer <!-- 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 . Please also write a comment on that issue linking back to this pull request once it is open. -- Adds support for the following matrix expressions to the NumPy printer: [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] <!-- 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 --printing numpy printer support for more matrix expressions <!-- END RELEASE NOTES --


() should return objects with no args instead of subclasses of Atom with no arguments returns subclasses of in . But the correct definition of a leaf node should be that it has no . This should be easy to fix, but one needs to check that this doesn't affect the performance.


combinatorics.Permutation - exception not raised if wrong size is passed to constructor If I create object from list, which length is greater than argument, then the argument is ignored (and exception is not raised): Is there any reason for such behaviour? It seems to me that it would be better to raise an exception.


Idx object can accepts non-integer bounds It is my understanding that this code should not work: the lower and upper bounds should be integers. Instead it runs without any errors: Note however that: produces the expected result: The check for integer dimension should be done to both upper and lower bounds when a tuple is given as argument.


BlockDiagMatrix with one element cannot be converted to regular Matrix Creating a BlockDiagMatrix with one Matrix element will raise if trying to convert it back to a regular Matrix: Instead having two elements will work as expected: This issue exists for sympy 1.5.1 but not for sympy 1.4


AttributeError: integrate(1 / (1 + x4)(S(1)/4), [x, 0, oo]) It is trying to compute the of a hypergeometric function:


Random test failing in testtensorpartial_deriv It happened in I suspect the problem is the random value sometimes get zero and doesn't evaluate.


sqrt(8)**Rational(2, 3) doesn't simplify The results should just be .


Added new feature SchurNumber <!-- I have a new feature in the combinatorics module the Schurnumber --The Schur number S(k) is the largest integer n for which the interval [1,n] can be partitioned into k sum-free sets. I have also made the partition which can be proven by induction and I have test cases


sqf and sqflist output is not consistant The example below is wrong in the sense that we should have (x*2 - 5_x + 6, 3) and not 2 factors of multiplicity 3. whereas below is correct --- one factor of multiplicity 2


Fix iszero and ispositive for Pow <!-- 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 . Please also write a comment on that issue linking back to this pull request once it is open. -- Still a work in progress. This attempts to get working in all cases. This PR fixes so that it doesn't assume finiteness unless justified by assumptions. For example on master: This is incorrect because if a or b can be infinite then it is possible for to be zero e.g. if is infinite and b is negative (a)<1 and b is positive infinite (oo) (a)1 and b is negative infinite (-oo) With this PR we have meaning that could be zero or could not be zero. Also on master we have whereas this PR gives in that case since could be zero and therefore not be positive. This PR also since This comes from the fact that is properly considered nonzero if is declared as finite. At the time of writing we still have this problem with the PR though: I'm not sure that this PR should be merged as is. Many of the changes are adding flags that probably shouldn't be there. Those flags would not be necessary if the other assumptions implied finite=True. For example in some cases a symbol is declared as and with this PR I've had to add also. Probably it would be better to fix those cases by having in the assumptions system. Most of the other cases are for symbols declared as which could also be fixed. Now that I (hopefully) have the tests passing I still want to improve this PR by tidying up the implementation. Also it still doesn't work in all cases as the zoo/n example above shows. Perhaps instead of merging this I could build new PRs on top. One could add . Then I could follow that with splitting real into extendedreal and real and having as well. That would be a big change though so maybe it would be better to merge this first. <!-- 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 --core Fix iszero assumptions for and when or could be infinite. <!-- END RELEASE NOTES --


Incorrect parenthesizing of Subs Here is an example. LaTeX printing of this gives: ! It would be better to be parenthesized to: !


Introduce 'evaluate' keyword argument in MatAdd and MatMul . Here is an example: I believe it would be better to add option which canonicallizes the object, so that


generate_derangements mishandles unsorted perm The following is incorrect: The routine is assuming that the is sorted (though this is not a requirement):


uniq modifies list argument When you iterate over a dictionary or set and try to modify it while doing so you get an error from Python: It would be good to do the same thing from within because the output will silently be wrong if you modify a passed list: I think this would entail recording the size at the start and then checking the size and raising a similar RuntimeError if the size changes.


Add more SciPy functions to code printer Here is a list of special functions supported in SciPy: Many of them are not supported in the SciPyPrinter and should be .


Incorrect plot with constants I have attached the screenshot of the plot. The x-axis gets moved to y=3, instead of creating a horizontal line at y=3. !


give a argument Like , I think a argument could be to so the length would be padded with 0s if necessary to reach the given bit length: Tests, too, should be .


Wrong matrix element fetched from BlockMatrix Given this code: I get this output: is the wrong here. should not be simplified as that element may come from either or .


isfiniteset property not implemented for Range Currently, returns nothing, since isfiniteset is not implemented in class Range. I'd like to do that. I was thinking of something like this: Any suggestions/views/ideas are highly appreciated. I will submit a PR for the above changes soon. Also there are some other issues, like: and don't work for ranges in which one of the elements is a symbolic integer, i.e., Any ideas regarding fixing the same are highly appreciated, I'd really like to fix it.


Factor with extension=True drops a factor of y-1 I guess this related (or a duplicate of?) This is from stackoverflow: Factor with extension=True drops a factor of y-1 <!-- Your title above should be a short description of what was changed. Do not include the issue number in the title. --Factor with extension=True drops a factor of y-1 <!-- 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 --NO ENTRY <!-- END RELEASE NOTES --


Tensor contractions are wrong This is essentially a generalization of . The problem in the current implementation is that contractions are handled before applications of the metric, which leads to incorrect results such as in . In : And thus, the issue is that is being called prior to (where the metric is applied). The reason that this ordering matters is because tensor contraction is itself the abstraction of applying the metric to the tensors that represent psuedo-riemannian manifolds. In essence, it means that we must have it that !; however, this isn't the case here. I've tried tampering with the code above, but by the way tensors have been designed, this bug is essentially unavoidable. As a consequence, the tensor module needs to be refactored in order to get accurate results. (Also, I couldn't help but notice that the last argument to isn't used). had mentioned that he had this sort of refactoring in the works, but based on his fork, progress seems to be slow. I think discussions should be in order for reorganizing how tensors actually represent their components in this module.


ZeroMatrix should not be falsey We have: I don't see any sense in having a ZeroMatrix instance evaluate to False. This happens because of the method defined for : The method is not needed now that Python 2 is not supported. The method is not needed because a should not evaluate to False in a boolean context. The linked lines of code should simply be removed.