May 02, 2019

This post has been cross-posted on the Quansight Blog.

As of November, 2018, I have been working at Quansight. Quansight is a new startup founded by the same people who started Anaconda, which aims to connect companies and open source communities, and offers consulting, training, support and mentoring services. I work under the heading of Quansight Labs. Quansight Labs is a public-benefit division of Quansight. It provides a home for a "PyData Core Team" which consists of developers, community managers, designers, and documentation writers who build open-source technology and grow open-source communities around all aspects of the AI and Data Science workflow. As a part of this, I am able to spend a fraction of my time working on SymPy. SymPy, for those who do not know, is a symbolic mathematics library written in pure Python. I am the lead maintainer of SymPy.

SymPy 1.4 was released on April 9, 2019. In this post, I'd like to go over some of the highlights for this release. The full release notes for the release can be found on the SymPy wiki.

To update to SymPy 1.4, use

conda install sympy

or if you prefer to use pip

pip install -U sympy

The SymPy 1.4 release contains over 500 changes from 38 different submodules, so I will not be going over every change, but only a few of the main highlights. A total of 104 people contributed to this release, of whom 66 contributed for the first time for this release.

While I did not personally work on any of the changes listed below (my work for this release tended to be more invisible, behind the scenes fixes), I did do the release itself.

Automatic LaTeX rendering in the Jupyter notebook

Prior to SymPy 1.4, SymPy expressions in the notebook rendered by default with their string representation. To get LaTeX output, you had to call init_printing():

SymPy 1.3 rendering in the Jupyter lab notebook

In SymPy 1.4, SymPy expressions now automatically render as LaTeX in the notebook:

SymPy 1.4 rendering in the Jupyter lab notebook

However, this only applies automatically if the type of an object is a SymPy expression. For built-in types such as lists or ints, init_printing() is still required to get LaTeX printing. For example, solve() returns a list, so does not render as LaTeX unless init_printing() is called:

SymPy 1.4 rendering in the Jupyter lab notebook with init_printing()

init_printing() is also still needed if you want to change any of the printing settings, for instance, passing flags to the latex() printer or selecting a different printer.

If you want the string form of an expression for copy-pasting, you can use print.

Improved simplification of relational expressions

Simplification of relational and piecewise expressions has been improved:

>>> x, y, z, w = symbols('x y z w')
>>> init_printing()
>>> expr = And(Eq(x,y), x >= y, w < y, y >= z, z < y)
>>> expr
x = y ∧ x ≥ y ∧ y ≥ z ∧ w < y ∧ z < y
>>> simplify(expr)
x = y ∧ y > Max(w, z)
>>> expr = Piecewise((x*y, And(x >= y, Eq(y, 0))), (x - 1, Eq(x, 1)), (0, True))
>>> expr
⎧ x⋅y   for y = 0 ∧ x ≥ y
⎨x - 1      for x = 1
⎩  0        otherwise
>>> simplify(expr)

Improved MathML printing

The MathML presentation printer has been greatly improved, putting it on par with the existing Unicode and LaTeX pretty printers.

>>> mathml(Integral(exp(-x**2), (x, -oo, oo)), 'presentation')

If your browser supports MathML (at the time of writing, only Firefox and Safari), you should see the above presentation form for Integral(exp(-x**2), (x, -oo, oo)) below:


Improvements to solvers

Several improvements have been made to the solvers.

>>> eq = Eq((x**2 - 7*x + 11)**(x**2 - 13*x + 42), 1)
>>> eq
               x  - 13⋅x + 42
⎛ 2           ⎞
⎝x  - 7⋅x + 11⎠               = 1
>>> solve(eq, x) # In SymPy 1.3, this only gave the partial solution [2, 5, 6, 7]
[2, 3, 4, 5, 6, 7]

The ODE solver, dsolve, has also seen some improvements. Two new hints have been added.

'nth_algebraic' solves ODEs using solve by inverting the derivatives algebraically:

>>> f = Function('f')
>>> eq = Eq(f(x) * (f(x).diff(x)**2 - 1), 0)
>>> eq
⎛          2    ⎞
⎜⎛d       ⎞     ⎟
⎜⎜──(f(x))⎟  - 1⎟⋅f(x) = 0
⎝⎝dx      ⎠     ⎠
>>> dsolve(eq, f(x)) # In SymPy 1.3, this only gave the solution f(x) = C1 - x
[f(x) = 0, f(x) = C₁ - x, f(x) = C₁ + x]

'nth_order_reducible' solves ODEs that only involve derivatives of f(x), via the substitution $g(x)=f^{(n)}(x)$.

>>> eq = Eq(Derivative(f(x), (x, 2)) + x*Derivative(f(x), x), x)
>>> eq
  d           d
x⋅──(f(x)) + ───(f(x)) = x
  dx           2
>>> dsolve(eq, f(x))
f(x) = C₁ + C₂⋅erf⎜────⎟ + x
                  ⎝ 2  ⎠

Dropping Python 3.4 support

This is the last release of SymPy to support Python 3.4. SymPy 1.4 supports Python 2.7, 3.4, 3.5, 3.6, 3.7, and PyPy. What's perhaps more exciting is that the next release of SymPy, 1.5, which will be released later this year, will be the last version to support Python 2.7.

Our policy is to drop support for major Python versions when they reach their End of Life. In other words, they receive no further support from the core Python team. Python 3.4 reached its end of life on May 19 of this year, and Python 2.7 will reach its end of life on January 1, 2020.

I have blogged in the past on why I believe it is important for library authors to be proactive in dropping Python 2 support, and since then a large number of Python libraries have either dropped support or announced their plans to by 2020.

Having Python 2 support removed will not only allow us to remove a large amount of compatibility cruft from our codebase, it will also allow us to use some Python 3-only features that will clean up our API, such as keyword-only arguments, type hints, and Unicode variable names. It will also enable several internal changes that will not be visible to end-users, but which will result in a much cleaner and more maintainable codebase.

If you are still using Python 2, I strongly recommend switching to Python 3, as otherwise the entire ecosystem of Python libraries is soon going to stop improving for you. Python 3 is already highly recommended for SymPy usage due to several key improvements. In particular, in Python 3, division of two Python ints like 1/2 produces the float 0.5. In Python 2, it does integer division (producing 1/2 == 0). The Python 2 integer division behavior can lead to very surprising results when using SymPy (imagine writing x**2 + 1/2*x + 2 and having the x term "disappear"). When using SymPy, we recommend using rational numbers (like Rational(1, 2)) and avoiding int/int, but the Python 3 behavior will at least maintain a mathematically correct result if you do not do this. SymPy is also already faster in Python 3 due to things like math.gcd and functools.lru_cache being written in C, and general performance improvements in the interpreter itself.

And much more

These are only a few of the highlights of the hundreds of changes in this release. The full release notes can be found on our wiki. The wiki also has the in progress changes for our next release, SymPy 1.5, which will be released later this year. Our bot automatically collects release notes from every pull request, meaning SymPy releases have very comprehensive and readable release notes pages. If you see any mistakes on either page, feel free to edit the wiki and fix them.

December 30, 2018

Conclusion of things done on weekend regarding learning word2vec.

  • word2vec is one of the really good ways to solve the problem of “word-embedding”. , developed by researchers at google (Tomas Mikolov and colleagues)

  • GloVe (Global Vectors for Word Representation) is another really good way to compute word embeddings, developed at Stanford.

  • The original research papers (by Tomas Mikolov and colleagues) on word2vec [1]. Efficient Estimation of Word Representation in Vector Spaces [2]. Distributed Representation of words and phrases and their composotionality

    these two papers on reading sucked the hell out of me (probably because I don’t have much background in Neural networks).

    Rather I found myself having to go through the paper [3]. word2vec explained: Deriving Mikolo et al’s negative sampling word embedding method

  • I’d a go through the lecture 7 (skipped the lectures 4, 5 and 6), to get an idea of what are deep learning frameworks like Tensorflow (lecuture 7 is an introduction to it). It gives a basic idea of why to use Tensorflow and performing basic operations with it.

  • All in all this weekend was all focused on things related to NLP stuff. I am hopeful that in the next year I might be able to take a few more step towards learning the NLP stuff.

November 06, 2018

GitHub recently announced its paper cuts initiative to fix minor issues that make things more difficult for GitHub users. As someone who spends most of his day on, this initiative is great, as these small cuts can quickly add up to a painful experience.

The initiative has already made some great fixes, such as making the diff markers unselectable and hovercards. Small changes like these are usually quite easy for GitHub to do, but they make a huge difference to those of use who use GitHub every day.

I recently asked how these cuts could be reported to GitHub for fixing, but got no response. So I am writing this blog post.

To be very clear: I think that on the whole GitHub is great and they are doing a great job. And it's still better than the alternatives (to put things in perspective, I recently spent half an hour trying to figure out how to change my password in BitBucket, and GitLab can't even keep me logged in between sessions). GitHub has and continues to revolutionize the open source ecosystem, and is still the best place to host an open source project.

But since GitHub did ask what sorts of changes they want to see, I'm providing a list. In this post I'm trying to only ask about things that are small changes (though I realize many won't be as easy to fix as they may appear from the outside, and I readily admit that I am not a web developer).

These are just the things that have bothered me, personally. Other people use GitHub differently and no doubt have their own pain points. For instance, I have no suggestions about the project boards feature of GitHub because I don't use it. If you are also a GitHub user and have your own pain points feel free to use the comment box below (though I have no idea if GitHub will actually see them).

If you work for GitHub and have any questions, feel free to comment below, or email me.

In no particular order:


  1. Allow anyone to add labels to issues. At the very least, allow the person who opened the issue to add labels.

  2. The new issue transfer ability is great, but please make it require only push access, not admin access.

  3. Remove the automatic hiding of comments when there are too many. I understand this is done for technical reasons, but it breaks Cmd-F/scrolling through the page to find comments. Often I go to an issue trying to find an old comment and can't because buried in the comments is a button I have to press to actually show the comment (it's even worse when you have to find and press the button multiple times).

  4. Better indication for cross-referenced pull requests. I really don't know how to fix this, only that it is a problem. It happens all the time that a new contributor comes to a SymPy issue and asks if it has been worked on yet. They generally do not seem to notice the cross-referenced pull requests in the list. Here is an example of what I'm talking about.

  5. Indicate better if a cross-referenced pull request would close an issue. Preferably with text, not just an icon.

  6. HTML pull request/issue templates. I don't know if this counts as a "cut", as it isn't a simple fix. Right now, many projects use pull requests/new issue templates, but it is not very user friendly. The problem is that the whole thing is done in plain text, often with the template text as an HTML comment to prevent it from appearing in the final issue text. Even for me, I often find this quite difficult to read through, but for new contributors, we often find that they don't read it at all. Sure there's no way to force people to read, but if we could instead create a very simple HTML form for people to fill out, it would be much more friendly, even to experienced people like myself.

  7. Fix the back button in Chrome. I don't know if this is something that GitHub can fix, and I also do not know how things work in other browsers. I use Chrome on macOS. Often, when I click the "back" button and it takes me back to an issue page, the contents of the page are out-of-date (the newest comments or commits do not appear). It's often even more out-of-date than it was when I left the page. I have to reload the page to get the latest content.

  8. Allow Markdown formatting in issue titles.

  9. Show people's names next to comments as "Real Name (@username)". In general, GitHub should be emphasizing people's display names rather than their usernames.

  10. Remember my selection for the "sort" setting in the issues list. I'd love to have issues/pull requests sort by "most recently updated" by default, so that I don't miss updates to old issues/pull requests.

  11. Make advanced search filters more accessible. They should autofill, similar to how Gmail or even GitLab search works (yes, please steal all the good ideas from GitLab; they already stole all their good ideas from you).

  12. Tone down the reaction emojis. Maybe this ship has sailed, but reaction emojis are way too unprofessional for some projects.

  13. Copy/paste text as Markdown. For example, copying "bold" and pasting it into the comment box would paste **bold**. Another idea that you can steal from GitLab.

  14. Strike out #12345 issue links when the issue/PR is closed/merged (like #12345).

Pull requests

  1. Add a button that automatically merges a pull request as soon as all the CI checks pass. Any additional commits pushed to the branch in the interim would cancel it, and it should also be cancellable by someone else with push access or the PR author.

  2. Add some way to disable the automatic hiding of large diffs. This breaks Cmd-F on the page, and makes it harder to scroll through the pull request to find what you are looking for (typically the most important changes are the ones that are hidden!).

  3. Include all issue/PR authors in the authors search on the pull request list page. Right now it only lists people with push access. But I generally can't remember people's GitHub usernames, and autofilling based on all authors would be very helpful.

  4. Better contextual guesses for issue autofilling (after typing #). For instance, if an issue has already been referenced or cross-referenced, it should appear near the top of the list. We have almost 3000 open issues in SymPy, and the current issue numbers are 5-digits long, so referencing an issue purely by number is very error prone.

  5. Auto-update edited comments. Context: SymPy uses a bot that comments on every pull request, requiring a release notes entry to be added to the description. This works quite well, but to prevent the bot from spamming, we have it comment only once, and edit its comment on any further checks. However, these edits do not automatically update, so people have to manually reload the page to see them.

  6. Don't hide full commit messages by default in the commits view. It would be better to encourage people to write good commit messages.

  7. Make issue cross-references in pull request titles work. I'd rather people didn't put issue numbers in pull request titles but they do it anyway, so it would be nice if they actually worked as links.

  8. Allow me to comment on lines that aren't visible by default. That is, lines that you have to click the "expand" icon above or below the line numbers to access. As an example, this can be useful to point out a line that should have been changed but wasn't.

  9. Copying code from a diff that includes lines that aren't visible by default includes an extra space to the left for those lines. This is a straight up bug. Probably fixing the previous point would also fix this :)

  10. Make searches include text from the pull request diff.

  11. When a diff indents a line color the whitespace to the left of the line. (see this)

  12. Pull requests can show commits that are already in master. For example, if someone makes pull request B based off of pull request A and then A gets merged, B will still show the commits from A. This has been a bug forever.

  13. Make the "jump to file or symbol" popdown collapsible. Specifically what I mean is I want to be able to show just the files, without any symbols. For large pull requests, it is very difficult to use this popdown if there are hundreds of symbols. I typically want to just jump to a specific file.

  14. The status check on the favicon goes away when you switch to the diff tab. Kudos to Marius Gedminas for pointing this out.

  15. Apparently status checks that use the GitHub Apps API are forced to link into the checks tab. The checks tab is useless if no information is actually published to it. It would be better if it could link straight to the external site, like is done with oauth integrations.

  16. Make it easier to copy someone's username from the pull request page. I generally do this to git remote add them (using hub). If I try to select their username from a comment, it's a link, which makes it hard to select. I generally copy it from the blue text at the top "user wants to merge n commits from sympy:master from user:branch". If it were easier to select "user" or "branch" from that box (say, by double clicking), that would be helpful.

  17. Change the "resolve conversation" UI. I keep pressing it on accident because it's where I expect the "new comment" button to be.


I wrote a whole post about the reviews feature when it came out. Not much has changed since then (actually, it has gotten worse). In short, the feature doesn't work like I would like it too, and I find the default behavior of deferred comments to be extremely detrimental. If there were a way to completely disable reviews (for myself, I don't care about other people using the feature), I would.

See my blog post for full details on why I think the reviews feature is broken and actually makes things worse, not better than before. I've summarized a few things that could change below.

  1. Make reviews non-deferred by default. This is the biggest thing. If I had to pick only a single item on this page to be changed, it would be this. The issue is if I start a review and walk away from it, but forget to "finalize" it with a review status, the review is never actually seen by anyone. The simplest way to fix this would be to simply make partial reviews public.

  2. Make Cmd-Enter default to immediate comment. Barring the above change, Cmd-Enter on a pull request line comment should default to immediate comment, not deferred (review) comment. The problem with the Cmd-Shift-Enter shortcut is that it is inconsistent: on a normal comment, it closes the pull request, and on a reply comment, it does nothing. I shouldn't have to check what "comment context" I am in to figure out what keyboard shortcut to use. The worst part is if you accidentally start a review, it's a pain in the ass to undo that and just post a normal comment. The simplest way to fix this would be to swap the current meaning of Cmd-Enter and Cmd-Shift-Enter for line comments (and no, this wouldn't be a backwards incompatible change, it would be a regression fix; Cmd-Enter used to do the right thing).

  3. Allow reviewing your own pull request. There's no reason to disallow this, and it would often be quite useful to, for instance, mark a work in progress PR as such with a "request changes" review. Obviously self-reviews would be excluded from any required reviews.

  4. Unhide the reviews box. It should just be the same box as the comment box, unstead of buried on the diff tab (see my blog post).

  5. Show review status in the pull request list as a red X or green check. This would make it easier to see which pull requests have reviews.

  6. Allow new commits to invalidate reviews. That way they work the same way as any other status check. (I see that this is now an option for required reviews, which is new since my original blog post, but it still doesn't affect the status as reported on the pull requests list).

  7. Allow requiring zero negative reviews to merge (but not necessarily any positive reviews). Requiring a positive review is pointless. The person merging can just add one real quick before they merge, but it is unnecessary extra work. On the other hand allowing people with push access to block a merge with a negative review would be very useful.

Web editor

  1. The web editor seems to have a search function, but I can't get it to actually work. Half the time Cmd-F pops open the browser search, which doesn't find text that isn't on screen. And when I press Cmd-G to actually do the search, it doesn't work (and there are no buttons to perform the search either).

  2. Add basic syntax testing in the web editor for common languages to catch basic mistakes.

Mobile site

  1. Please make the mobile site work with iOS 10. I don't see any reason why simple things like buttons (like the merge button or the comment button) shouldn't work on a slightly older browser. No, I am not a web developer, but I do use my phone a lot and I've noticed that literally every other website works just fine on it.

  2. Add a way to disable the mobile site permanently. For the most part, the mobile site is useless (see below). If you aren't going to put full development effort into it, allow me to disable it permanently so that every time I visit on my phone it goes to the desktop site.

Seeing as how the site (mobile or not) is almost completely unusable on every mobile device I own, it's hard to list other things here, but based on back when it actually worked, these are some of the things that annoyed me the most. Basically, I have found that virtually every time I go to GitHub to do anything on mobile, I have to switch to desktop mode to actually do what I want.

My apologies if any of these actually work now: as I said, doesn't actually work at all on my phone.

  1. Cannot search issues on mobile.

  2. Cannot make a line comment that isn't a review on mobile.

  3. Cannot view lines beyond the default diff in pull requests on mobile.

  4. Show more than 2 lines of the README and 0 lines of the code by default on project pages. Yes mobile screens are small but it's also not hard to scroll on them.

  5. Support Jupyter notebook rendering on mobile.

Files view

  1. GitHub needs a better default color theme for syntax highlighting. Most of the colors are very similar to one another and hard to differentiate. Also things like strings are black, even though one of the most useful aspects of syntax highlighting generally is to indicate whether something is in a string or not.

  2. Add MathJax support to markdown files. This would be amazingly useful for SymPy, as well as many scientific software projects. Right now if you want this you have to use a Jupyter notebook. MathJax support in issue/pull request comments would be awesome as well, though I'm not holding out for that.

  3. Add "display source" button for markdown, ReST, etc. I mean the button that is already there for Jupyter notebooks. Right now you have to view markdown and ReST files "raw" or edit the file to see their source.

  4. Add a link to the pull request in the blame view. Usually I want to find the pull request that produced a change, not just the commit.


  1. The wikis used to support LaTeX math with MathJax. It would be great if this were re-added.

  2. The ability to set push permissions for the wiki separately from the repo it is attached to, or otherwise create an oauth token that can only push to the wiki would be useful. Context: for SymPy, we use a bot that automatically updates our release notes on our wiki. It works quite well, but the only way it can push to the wiki is if we give it push access to the full repo.

Notification emails

  1. Don't clobber special emails/email headers. GitHub adds special emails like and to email notifications based on how the notification was triggered. This is useful, as I can create an email filter for for notifications on issues and pull requests created by me. The bad news is,, which is added when I am @mentioned, clobbers, so that it doesn't appear anymore. In other words, as soon as someone @mentions me in one of my issues, I become less likely to see it, because it no longer gets my label (I get @mentioned on a lot of issues and don't have the ability to read all of my notification emails). Ditto for the X-GitHub-Reason email headers.

  2. Readd the "view issue" links in Gmail. (I forgot what these are called). GitHub notification emails used to have these useful "view issue" buttons that showed up on the right in the email list in Gmail, but they were removed for some reason.


  1. Make the requests in the API docs actually return what they show in the docs. This means the example repo should have actual example issues corresponding to what is shown in the docs.

  2. Allow giving deploy key access to just one branch. That way I can have a deploy key for gh-pages and minimize the attack surface that the existence of that key produces. I think everyone would agree that more fine-grained permissions throughout the API would be nice, but this is one that would benefit me personally, specifically for my project doctr.

GitHub Pages

GitHub pages is one of the best features of GitHub, and in fact, this very blog is hosted on it. Very few complaints here, because for the most part, it "just works".

  1. Moar themes. Also it's awesome that you can use any GitHub repo as a theme now, but it turns out most random themes you find around GitHub don't actually work very well.

  2. The steps to add HTTPS to an existing GitHub pages custom domain are a bit confusing.. This took us a while to figure out for To get things to work, you have to trigger GitHub to issue a cert for the domain. But the UI to issue the cert is to paste the domain into the box. So if the domain is already there but it doesn't work, you have to re-enter it. Also if you want both www and the apex domain to be HTTPS you have to enter them both in the box to trigger GitHub to issue a cert. This is primarily a UX issue. See


  1. Automatically protected branches make the branch difficult to delete when you are done with it. My use-case is to create a branch for a release, which I want to protect, but I also want to delete the branch once it is merged. I can protect the branch automatically pretty easily, but then I have to go and delete the protection rule when it's merged to delete it. There are several ways this could be fixed. For instance, you could add a rule to allow protected branches to be deleted if they are up-to-date with default branch.

  2. Add a way to disable the ability for non-admins to create new branches on a repo. We want all of our pull requests to come from forks. Branches in the repo just create confusion, for instance, they appear whenever someone clones the repository.

  3. Related to the previous point, make pull request reverts come from forks. Right now when someone uses the revert pull request button, it creates a new branch in the same repo, but it would be better if the branch were made in the person's fork.

  4. Allow me to enable branch protection by default for new repos.

  5. Allow me to enable branch protection by default on new branches. This is more important than the previous one because of the feature that lets people push to your branch on a pull request (which is a great feature by the way).

  6. Clicking a team name in the settings should default to the "members" tab. I don't understand why GitHub has a non-open "discussions" feature, but I find it to be completely useless, and generally see such things as harmful for open source.

  7. Suggest people to add push access to. I don't necessarily mean passively (though that could be interesting too), but I mean in the page to add someone, it would be nice if the popup suggested or indicated which people had contributed the project before, since just searching for a name searches all of GitHub, and I don't want to accidentally give access to the wrong person.


  1. Stop trying to make profile pages look "cute" with randomly highlighted pull requests. GitHub should have learned by now that profile pages matter a lot (whether people want them to or not), and there can be unintended consequences to the things that are put on them.

  2. Explain what the axes actually mean in the new "activity overview". I'm referring to this (it's still in beta and you have to manually enable it on your profile page). Personally I'm leaving the feature off because I don't like being metricized/gamified, but if you're going to have it, at least include some transparency.


  1. Allow hiding the "source code (zip)" and "source code (tar.gz)" files in a release. We upload our actual release files (generated by to the GitHub release. We want people to download those, not snapshots of the repo.


  1. The repository search function doesn't support partial matches. This is annoying for conda-forge. For instance, if I search for "png" it doesn't show the libpng-feedstock repo.

  2. Show commit history as a graph. Like git log --graph. This would go a long way to helping new users understand git. When I first started with git, understanding the history as a graph was a major part of me finally grokking how it worked.

  3. Bring back the old "fork" UI. The one that just had icons for all the repos, and the icons didn't go away or become harder to find if you already had a fork. Some of us use the "fork" button to go to our pre-existing forks, not just to perform a fork action. This was recently changed and now it's better than it was, but I still don't see why existing forks need to be harder to find, visually, than nonexisting ones.

  4. Provide a more official way to request fixes to these cuts. I often ask on Twitter, but get no response. Preferably something public so that others could vote on them (but I understand if you don't want too much bikeshedding).

August 22, 2018

Today’s day started with receiving an email from Google. Here is a snapshot:

This left a big smile on my face 😄

The past 3-4 months have been amazing and I have learnt a lot during the course of time. I would like to thank Aaron, Ondrej and the SymPy team for providing me with this opportunity, my mentor Amit Kumar for guiding me all through the phases and a special thanks to Chris who was not officially my mentor but was present all the time for reviweing my work and helping me complete the project successfully.

Here is what Amit has to say:

Though GSoC is completed I will be continuing my contribution in the developement of the software.

August 14, 2018

This post summarizes the work done on the Group Theory part of the combinatorics module during 2018 summers as a part of the GSoC programme

This post summarises the work that I have done during GSoC for SymPy. The links to the Pull Requests are in chronological order under each header. For following the progress made during GSoC, see my weekly posts.

This summer has been a great learning experience and has helped me get a good exposure of test-driven development. I plan to actively review the work that has went into this project and continue contributing to SymPy. I am grateful to my mentors, Kalevi and Aaron for reviewing my work, giving me valuable suggestions, and being readily available for discussions.

Pull Requests

This is the list of merged Pull Requests.

Major Additions

  • sympy/sympy#14725: Add discrete module, and transforms sub-module including Fast Fourier Transform, Number Theoretic Transform, and include docstring, doctests, unit-tests.
  • sympy/sympy#14745: Add convolution sub-module including convolution_fft, convolution_ntt and a general method convolution for identifying the type of convolution and handling the cyclic convolution case, and include docstring, doctests, unit-tests.
  • sympy/sympy#14765: Implement Walsh Hadamard Transform and include doctests, unit-tests, docstring for the same.
  • sympy/sympy#14783: Implement convolution_fwht and add support for keyword dyadic in the general convolution method, and include docstring, doctests, unit-tests.
  • sympy/sympy#14816: Add a method linrec which allows evaluation of linear recurrences without obtaining closed form expressions, and include tests for the same.
  • sympy/sympy#14853: Implement Möbius Transform using Yate’s Dynamic Programming method while having subset keyword for flexibility of the implementation, and include docstring, doctests, unit-tests.
  • sympy/sympy#14878: Implement subset convolution and include docstring, doctests, unit-tests.
  • sympy/sympy#14928: Add covering product in convolutions sub-module and include docstring, doctests, unit-tests.
  • sympy/sympy#14954: Add intersecting product in convolutions sub-module and include docstring, doctests, unit-tests.

Documentation and Code Refinements

  • sympy/sympy#14969: Improve Sphinx docs for SymPy, use plural module names - convolutions and recurrences, refine the documentation for discrete module.
  • sympy/sympy#14994: Add reStructuredText file for discrete module for inclusion in Sphinx docs, which can be referred here.
  • sympy/sympy#15025: Refine discrete module to fix tests using floats instead of Rationals, adding warning about sequence size for fft and other improvements.

Additional Improvements

  • sympy/sympy#14712: Add .rewrite(exp) capability for instances of Pow and fix bugs in solvers module.
  • sympy/sympy#14907: Fix exception handling for factorial modulo and refine the signature for general convolution method.
  • sympy/sympy-bot#18: Fix the issue of incorrect links being referred in wiki by explicitly specifying the links instead of using relative paths.

Future Work

  • Adding a user-facing public method that internally calls discrete.recurrences.linrec and possibly extending it for different types of recurrences as well.
  • Making methods fft and convolution_fft efficient for both symbolic and numeric variants, as some discussion and benchmarking has been done for it and there is some work done by Colin for implementing a ComplexFloat class in sympy/sympy#12192 which would be very helpful for the same.

August 11, 2018

About Me:

I am Nikhil Pappu, an undergraduate Computer Science student at the International Institute of Information Technology, Bangalore.

About the Project:

Autolev (now superseded by MotionGenesis) is a domain specific language used for symbolic multibody dynamics. The SymPy mechanics module now has enough power and functionality to be a fully featured symbolic dynamics module. The parser parses Autolev (version 4.1) code to SymPy code by making use of SymPy’s math libraries and the mechanics module.

The parser has been built using the ANTLR framework and its main purpose is to help former users of Autolev to get familiarized with multibody dynamics in SymPy.

The Plan:

The plan was to build a parser using ANTLR that could parse Autolev code to SymPy code.  Overall,  I think I was able to achieve most of what I had hoped for. I had faced some difficulties in some areas of the parser due to the very different nature of Autolev and Python. The parser has some issues as a result. I have specified all the details in the documentation I have written.

Work Done:

I made a parser for the Autolev language which is now a part of SymPy in the parsing module. I have written the code for the parser using the ANTLR framework. I have also included a bunch of tests for testing the rules of the parser code.

The majority of the work was a part of PR #14758. I made a second PR #15006 for the changes I had made after the main PR.

I have written documentation for the parser which is a part of these PRs: #15046, #15066 and #15067.

I have also written a PyDy for Autolev Users guide which is a part of PR #15077. This guide is meant to be a quick reference for looking up Autolev-PyDy equivalents.

Future Work:

  1. The parser has been built by referring to and parsing codes from the Autolev Tutorial and the book Dynamics Online: Theory and Implementation Using Autolev. Basically, the process involved going through each of these codes, validating the parser results and improving the rules if required to make sure the codes parsed well.

    As of now, a large number of codes of Dynamics Online have been parsed. Completing all the remaining codes of the book would make the parser more complete.

  2. There are some limitations and issues with the parser and these have been discussed in the documentation. The plan is to fix these in order of priority.
  3. The parser is currently built using a kind of Concrete Syntax Tree (CST) using the ANTLR framework. It would be ideal to switch from a CST to an Abstract Syntax Tree (AST). This way, the parser code will be independent of the ANTLR grammar which makes it a lot more flexible. It would also be easier to make changes to the grammar and the rules of the parser.

I would like to keep contributing to SymPy. I would be doing a lot of math in college especially related to data science so I would love to contribute in areas like Probability and Algebra among others. I would also like to help newcomers feel comfortable with the environment.


I would like to thank my mentors Ondřej Čertík and Jason Moore for believing in me and taking time out from their busy schedules to guide me throughout the project. I would also like to thank Aaron Meurer for looking over GSoC as the org admin and making sure that we all had a great experience working with SymPy.


Main PR: #14758

Updated parser code PR: #15006 and #15013

Documentation PRs: #15046, #15066 and #15067

PyDy for Autolev Users guide PR: #15077

Weekly Blog link:

August 09, 2018

This week I continued the work with log solver and lambert solver. The log solver implementation is almost done with just few check for assumptions. Symbolic logarithmic equations should be dealt with proper assumptions. Such equations would give unsolved instance of ConditionSet otherwise.

>>> a, b, x = symbols('a, b, x')
>>> solveset(a**x - b**(x + 1), x, S.Reals)
ConditionSet(x, Eq(a**x - b**(x + 1), 0), S.Reals)
# because the bases (here, `a and b`) should have a positive value > 0)

>>> a, b = symbols('a b', positive=True)
>>> solveset(a**x - b**(x + 1), x, S.Reals)
{log(b)/(log(a) - log(b))}

Discussions with Amit and Chris suggested that there should be some other way to handle vanilla symbols. There should be atleast a ValueError or something else that would tell the user why this cannot be solved. Chris suggested of returning a Piecewise as object for this scenario. Something like:

cond = True if fuzzy_and([a > 0, b > 0, Eq(im(f), 0), Eq(im(g), 0)]) else False
Piecewise((solutions, cond), ConditionSet(........),  True))

Using Piecewise was not the greatest of the option as:

  • Though the assumptions were checked but it didn’t provided information to the user that why did it not solved.

  • Also using Piecewise had some problem causing recursion error, though it could be solved but it would make things unncessarily complicated.

  • Also solveset is not made to return objects other than Sets.

So we switched to a completely different approach. We tried using a different type of ConditionSet: providing the information within it that is necessary for the equation to be solved. The approach was: Force the equation to get solved but return a ConditionSet (a different than ususal) with the required assumptions, like: ConditionSet(x, And(a_base>0, b_base>0, Eq(im(a_exp), 0), Eq((im(b_exp), 0))), {solutions}). So now the above equation would return solutions something like: ConditionSet(x, (a > 0) & (b > 0), Intersection(Reals, {log(b)/(log(a) - log(b))}))

So this approach has been applied in the PR as of now, only a few minor changes needs to be done. I will try to finish this by the end of the week.

Apart from this some work has been done in lambert solver:

  • Used _is_lambert to identify lambert type equations.
  • Implemented bivariate solver (I will add a commit for this soon).
  • Ran solve’s tests, to get an idea of the extent to which solveset would handle such equations.

What’s next:

I will try to wrap up the work of both the PR’s. Lambert solver PR would need a bit more time for reviewing but nevertheless I will be continuing its work post GSoC. Implementing these two solvers will make solveset fully functional to handle transcendental equations which is a major part of my GSoC propsal. There will be a few minor things left that I will try to finish post GSoC. Also since this is the last week for the coding period, I will be needing to submit a final report of my work, I will complete and submit it before the deadline.

August 07, 2018

The final week of Coding Period has completed.

This week, the work was mainly concerned with the documentation and refinements in the discrete module. I started by opening PR #14994 to update Sphinx docs for SymPy. Kalevi and Aaron were kind enough to review the PR and help refine it for the final merge. The documentation for discrete module is now part of the SymPy docs and can be referred here.

Late this week, I opened PR #15025 for improvements in the discrete module. Colin helped fix accidental floats in unit tests (which should have been Rationals). After the review, the PR was merged successfully.

Future work would include - addition of a user-facing public method for linrec and making methods fft and convolution_fft efficient for both symbolic and numeric variants, as some discussion and benchmarking has been done for it and there is some work done by Colin for ComplexFloat class in PR #12192 which would be helpful for the same.

Looking forward to the concluding phase, where I will be wrapping up GSoC and preparing the report for the final evaluation.

August 03, 2018

I have made some changes to the parser code to parse more files since #14758 has been merged. I have also made the changes suggested in that PR after it had been merged. I have opened a new PR #15006 for the updated parser code. I have also opened #15013 to include tests for physics functions which I didn’t do in the initial PR. The GitLab repo autolev-test-examples is in good shape now and is part of the sympy user.

I am currently writing the documentation in which I shall include how to use the parser, gotchas, limitations, issues and future improvements. I shall also include a rewritten version of the PyDy for Autolev Users guide in it.

I shall then write the output tests (Tests to compare the outputs of Autolev against those of SymPy) for most of the test examples in the GitLab repo (I shall include these in a directory called output-tests in the GitLab repo). I think its good to put them here as I don’t see the need to test these on Travis as changing the parser code won’t affect these. Plus, they will be in a place where the test examples are which are what they will be based on. We could still test these on Travis if required even from here I suppose.

Finally, I shall wrap things up with the Final Report and Submission.

July 30, 2018

Last week, I created #14967 for implementation of plotting methods. Soon after pushing my commits, many of the jobs failed on Travis. It was strange as I was not able to reciprocate the errors locally.

After discussing it on Gitter, I got to know that it was due to the printing of plots using TextBackend in the doctest in absence of matplotlib. As matplotlib was present in my system,  doctest used matplotlib backend instead of TextBackend locally, hence passing all tests. Kalevi suggested using unset_show to stop the printing of plots during doctest but apparently, unset_show didn’t work for TextBackend. This was fixed by #14984 later that day and #14967 passed all the tests after former one was merged.

This week, I also started editing #14453 for documentation. It included a few beam problems along with their ascii diagrams.

Next Week

  • Make sure #14967 and#14453 gets merged.
  •  Add more beam problems for documentation.

July 29, 2018

Hello everyone. Here is the brief progress of Rubi module in the 11th week of GSoC period.

The main PR, which contains the major changes of this GSoC period was merged this week. I had not run pyflakes on it. I ran pyflakes on the main PR and fixed undefined issues. 

This week was mainly spent to test code generation. Initially, there was some error in generating the code. An issue was opened in this regard. I tried various other structure of Rubi to get it working.  Currently, patterns are not matched correctly. I have opened a PR for this. We are still trying to get the code generator working so that we can reduce the loading time of rules. Now, the loading time of all rules is around 10 minutes.

So this week I started up with implementing and sending a PR for lambert solver #14972. Solving these equations can be achieved by _solve_lambert routine of It is really powerful and can solve a varied type of equations having a general form. Another routine comes into action, the bivariate_type to solve majorly lambert type of equations when the former is unable to solve. These two routines can be handy for implementing such equations. As of now I have added _solve_lambert() in the PR. I will add bivariate_type once the log solver PR gets finalised. There are few equations that can be solved by posifying the variable that needs to be solved. A bit discussion is needed on this part.

Apart from this, a lot of work was done in the log solver PR

  • _term_factors() is used again.

  • Logic for exponential identifying is modified to not identify lambert type equations

  • Few mores tests were added.

  • Chris advised to make identification helpers such that they identify their class even if they won’t get solved by their respective solvers, the equation should not be passed to any of the other helpers for further solving. This wasn’t the case before, the identifying helpers were implemented only for equations that their helpers could solve. So now this idea is implemented for both the exponential and logarithmic solver. Equations that these identifiers can’t identify will be further solved as lambert type.

Almost all the work of the log solver PR is done. I will be finishing the work on lambert solver PR and complete in coming week. I hope both the PR’s gets merged before the GSoC period ends.

July 28, 2018

This week, I started working on adding the final method to convolution module for Intersecting Product. PR #14954 dealt with the addition of intersection_product method. Intersecting Product was implemented using Möbius Transform with superset enumeration (mobius_transform(..., subset=False) and inverse_mobius_transform(..., subset=False)). After minor documentation improvements, the PR was merged successfully. The proposed transforms and convolutions are now part of sympy.discrete. The basic usage for the method is:

>>> from sympy import symbols, S, I, intersecting_product
>>> u, v, x, y, z = symbols('u v x y z')

>>> intersecting_product([u, v], [x, y])
[u*x + u*y + v*x, v*y]
>>> intersecting_product([u, v, x], [y, z])
[u*y + u*z + v*y + x*y + x*z, v*z, 0, 0]

Late this week, I started working on improving the documentation for SymPy’s Sphinx docs ( and other minor changes in the PR #14969. Also, issue #14964 was opened to discuss the possibility of using LaTeX in docstrings for SymPy documentation. The following changes were part of the PR:

  • Use LaTeX for docstrings in functions.combinatorial (reference to #14964)
  • Include genocchi and partition numbers in sphinx docs
  • Improve docstrings with single and double backticks for sphinx docs
  • Use plural module names under discrete (discrete.convolutions and discrete.recurrences)
  • Add graphviz as a prerequisite in sympy/doc/README.rst for Debian/Ubuntu
  • Fix links in references containing rounded braces and unicode chars for sphinx docs
  • Miscellaneous improvements to documentation

Successive reviews and discussions were helpful in finalizing the Pull Requests.

Looking forward to the final week of Coding Period.

July 27, 2018

Hello Everyone. I have been working on getting the PR #14758 into shape and now it is finally merged. I have written my own tests for the PR so as to not include copyrighted files that belong to the creators of Autolev.

I am now working on a test-examples repo which serves as a showcase of the parser and also as a source of additional tests. The repo is private on GitLab as it contains copyrighted files. You can request access at the repo link above. Files from this repo can be copied over to the test_examples folder of parsing/autolev to use them as tests. From now, I will be working on adding more examples from the PyDy example repo, Autolev Tutorial, and Dynamics Online to this repo while improving the code of the parser to parse all these codes. I am also making note of things like errors, inaccuracies etc to include them in the Documentation.

I will open another PR once I have made enough number of changes to the parser code.

Here is my plan for the future of this project:

Till the end of GSoC:

  1. Work on getting the test-examples repo in good shape.
  2. Write extensive Documentation (explaining what the parser can do, how to use it,  limitations, issues, future improvements etc).
  3. Work on as many Dynamics Online codes (which I shall include in the repo) as possible (Wrap up Ch4 and hoping to get half of Ch5 done (as it is quite big)).

Post GSoC:

  1. Finish the rest of the Dynamics Online Book (Whatever is left of Ch5 and also Ch6 which I think is less important).
  2. Work on the issues that I will be listing down in the documentation one by one after discussing the possible fixes (Some of these might require changes in the parser while some others require changes in the SymPy code while I do not have much of an idea about the fixes of some other ones).




July 24, 2018

This week I started working on implementing methods to plot Shear force, bending moment, slope and deflection diagrams. #14967 was created for it.

Mainly four methods were added to the Beam class:

  • plot_shear_force: This method returns a plot for Shear force present in the Beam object.
  • plot_bending_moment: This method returns a plot for Bending moment present in the Beam object.
  • plot_slope: This method returns a plot for slope of the elastic curve of the Beam.
  • plot_delfection: This method returns a plot for the deflection curve of the Beam object.
  • plot_loading_results: This method returns fig object containing subplots of Shear Force, Bending Moment, Slope and Deflection of the Beam object.

Here is a sample notebook demonstrating how to use these plotting methods.

Next Week

  • Make sure #14967 gets merged.
  • Add more beam problems to the documentation.

July 22, 2018

Hello everyone. Here is the brief progress of Rubi module in the 10th week of GSoC period.

Last week, we were able to load all rules. Rubi has now come in a very stable and working condition. One Missing thing in the main PR was missing instructions and documentation. This week I tried my best to write instructions, so that a new user can easily get familiar with it. I have kept it really simple.

Initially, I wrote a script in Mathematica to generate downvalues in separate files. This was done till now manually, but now it's automated. Then I wrote a sympy script to generate all rules and constraints in proper files directly just by running a function.
For a more easier understanding of steps, I created `` explaining all steps.

Next thing I realised that it would be good if we create a parsing script for the tests too. Till now I used maple format. But a lot of manual things were required. So I wrote a script which directly parses tests into sympy format. All this are added properly in ``.
`init` in Rubi too was updated with proper explanation of basic structure of rules and constraints. I also updated docs of few important utility_functions.

Now a new user can easily get familiar with Rubi and working with it will be simple.

I have also opened a new PR for new utility_functions. Once the old PR gets merged, we can merge this.

This week started with the merge of the PR #14736. Yehhhh!!!!!. So now solveset will be able to solve a varied type of exponential equations. Next work is going on to build the logarithmic and lambert solver.

A lot of discussion has been taken place over the implementation of the logarithmic solver, there were mainly two points to consider:

  • How the logarithmic equation gets evaluated, i.e., should we consider solutions that would make the log term negative.

Take for instance a logarithmic equation log(x - 3) + log(x + 3) = 0, when solved the solutions would be -sqrt(10) and sqrt(10), but -sqrt(10) make the log term negative. So the question was what should we do for such a scenario? Should we add a check to remove these solution or just accept. it.

As of now as suggested by Kalevi and Aaron we should focus on the liberal interpratation for evaluating equations: if an expression can be written in its equivalent form and makes sense then we can consider solutions of this equivalent form. Therefore both the above solutions are acceptable.

  • How the identification of the logarithmic equations would take place.

The identification of logarithmic type is another question and is still yet to be agreed upon. At first the implementation was done by extracting each term of the expression and see if it has log terms in it, this wasn’t the best of the method as we are trying to identify a large class of logarithmic equation while solving is done only for a subset of those equations (only those that can be reduced by logcombine). So Amit and Chris stressed upon making the logarithmic identification for equations that its solver would solve. So as of now I have made changes accordingly.

Another problem that this PR is facing is of the infinite recursion. The equations that both exponential and logarithmic can’t solve but still their respective solver try to handle gets into infinite recursion. One way (though not appropriate) is to use flags like in solve, using this would remove the infinite recursion but is not the best way to handle, therefore I am looking into ways on how to get this fixed.

Apart from the work on log solver, I did some work on lambert solver- how the implementation would go, ran all the tests of solve, differentiated the tests that _solve_lambert could solve and that bivariate_type would. I will be adding a PR for this in a day or so.

Next week goals:

  • Finish things with logarithmic solver

  • Sending a PR for lambert solver and try to finish its work as quickly as possible.

July 21, 2018

This week SymPy 1.2 was released, which included the discrete module. The complete changelog for the SymPy 1.2 is here. I started the week by cleaning up discrete module, improving the API of public convolution method by attending to reviews by Aaron and Kalevi and fixing issue #14901 reported by Aaron in PR #14907.

The PR #14907 has been merged successfully and will be part of SymPy 1.2.1.

Late this week, I started working on the convolution module for inclusion of covering_product. The PR #14298 included the same with documentation, doctests and unit tests. The implementation of covering_product uses Möbius Transform with subset enumeration (mobius_transform(..., subset=True) and inverse_mobius_transform(..., subset=True)). As included in the PR, the usage for the same is:

>>> from sympy import symbols, covering_product
>>> u, v, x, y, z = symbols('u v x y z')

>>> covering_product([u, v], [x, y])
[u*x, u*y + v*x + v*y]

>>> covering_product([u, v, x], [y, z])
[u*y, u*z + v*y + v*z, x*y, x*z]

Looking forward to the next week, where I will be implementing intersecting_product as the final method for the convolution module.

July 20, 2018

I have been working on improving the parser by parsing Dynamics online codes, planning out how to go about writing tests and other aspects of the project and getting the PR into shape.

I am currently working on writing tests to cover all the rules of the parser. I should be done with this in 2 days.

This is the plan I have for the third phase:

  1. Make the PR merge ready:
    1. Finish the tests for the parser rules and get the PR merged.
    2. open a new PR to work on further improvements.
  2. additional_tests (will be added in a private BitBucket repo). Here I shall go through many codes from these sources and improve the parser to parse most of these. I shall take notes on little details and errors so that I can include them in the documentation.
    1. PyDy example repo (mass spring damper, double pendulum, chaos pendulum examples)
    2. Dynamics Online Chapters 1 – 4
    3. Autolev Tutorial Examples (5.1 – 5.7)
  3. Documentation (What the parser can do, How it should be used, Limitations, Future improvements etc)
  4. Make the parser parse Dynamics Online Chapter 5 codes and the Bicycle Model.
  5. Final Report

July 17, 2018

I started implementing Beam_3d class which can be used to find Shear force, Bending moment, Slope, Deflection and other few things for the Beam object.  PR #14883 was created for this.

I implemented Beam_3d class using  this paper as a reference. Actually, like Beam class, it uses a few sets of equations to find certain quantities:

  • To find Shear force and Bending moment
    where [N, Qy, Qz] and [Mx, My, Mz] are the shear force and bending moment along x-y-z-axes respectively (q and m are applied load and moment).
  • To find Slope and Deflection:
    where [wx, wy, wz] and x, θy, θz] are deflection and slope along three axes respectively.

Example for the API:

There is a beam of l meters long. A constant distributed load of magnitude q
is applied along the y-axis from start till the end of the beam. A constant distributed
moment of magnitude m is also applied along the z-axis from start till the end of the beam. Beam is fixed at both of its end. So, deflection of the beam at the both ends
is restricted.

>>> from sympy.physics.continuum_mechanics.beam import Beam_3d
>>> from sympy import symbols
>>> l, E, G, I, A = symbols('l, E, G, I, A')
>>> b = Beam_3d(l, E, G, I, A)
>>> b.apply_support(0, "fixed")
>>> b.apply_support(l, "fixed")
>>> q, m = symbols('q, m')
>>> b.apply_load(q, dir="y")
>>> b.apply_moment_load(m, dir="z")
>>> b.shear_force()
[0, -q*x, 0]
>>> b.bending_moment()
[0, 0, -m*x + q*x**2/2]
>>> b.solve_slope_deflection()
>>> b.slope()
[0, 0, l*x*(-l*q + 3*l*(A*G*l**2*q - 2*A*G*l*m + 12*E*I*q)/(2*(A*G*l**2 + 12*E*I)) + 3*m)/(6*E*I)
+ q*x**3/(6*E*I) + x**2*(-l*(A*G*l**2*q - 2*A*G*l*m + 12*E*I*q)/(2*(A*G*l**2 + 12*E*I))
- m)/(2*E*I)]
>>> b.deflection()
[0, -l**2*q*x**2/(12*E*I) + l**2*x**2*(A*G*l**2*q - 2*A*G*l*m + 12*E*I*q)/(8*E*I*(A*G*l**2 + 12*E*I))
+ l*m*x**2/(4*E*I) - l*x**3*(A*G*l**2*q - 2*A*G*l*m + 12*E*I*q)/(12*E*I*(A*G*l**2 + 12*E*I)) - m*x**3/(6*E*I)
+ q*x**4/(24*E*I) + l*x*(A*G*l**2*q - 2*A*G*l*m + 12*E*I*q)/(2*A*G*(A*G*l**2 + 12*E*I)) - q*x**2/(2*A*G), 0]


As this class is relatively new, it would require a few improvements in the future:

  • As Beam_3d doesn’t use SingularityFunction, I was unable to find a way to represent point load/moments. So for now Beam_3d  only supports continous load (applied over the whole span length of beam).
  • Also, This class assumes that any kind of distributed load/moment is
    applied throughout the span of a beam.

For now, after discussing it with Arihant, we decided to raise NotImplementedError in such cases.

Next Week

  • Make sure PR #14883 gets merge by the end of next week.
  • Start implementing plotting methods for Beam class.

July 15, 2018

Hello everyone. Here is the progress of rubi module in the 9th week of GSoC period.

In the very beginning of the week, the PR for appelf1 was merged. My aim for this week was to load all rules and test at least a small part for each type of rule. Due to the time factor, its not possible to test all. Moreover, rubi needs to be updated to the latest version, so the test suite too will be updated.  

I started with trigo rules. They are huge in number. They were never tested before, so some utility_functions like `TrigReduce`, `KnownTrigIntegrandQ`, `FunctionOfTrig` etc were wrong. They were corrected. Soon I realised a difference between sympy and Mathematica. In mathematica, `1/Cot[x]` is automatically transformed to `Tan[x]` and `1/Tan[x]` too was transformed to `Cot[x]`. But in sympy, these are different. So, `tan(x)` didn't match to `cot(x)` . Francesco suggested to replace all `cot` with `1/tan`  and similarly for `sec` and `csc` (in the code generator too). 

Next, I moved to `inverse_trigo`, `hyperbolic` and `inverse_hyperbolic`. I tested some test cases for all these rules. I also tested `error_functions` completely to make sure `special_functions` are working properly. 

After all this, I feel rubi is in a stable and working condition. The loading time is around `10 minutes`. Except for the loading time, the performance of rubi is good. 

I have left `DerivativeIntegration` and `Piecewise` rules. We will be discussing it. 

July 14, 2018

The second phase of Coding Period has concluded.

This week I worked on implementing Subset Convolution for discrete module. PR #14878 was opened for the same. The PR included unit tests, documentation, and correspondingly subset keyword was added for public convolution method.

After discussing the implementation details and references with Kalevi, the approach was finalized. The PR has been merged successfully. The usage for the same is:

>>> from sympy.discrete.convolutions import (convolution, convolution_subset)
>>> u, v, x, y, z = symbols('u v x y z')

>>> convolution_subset([u, v], [x, y])
[u*x, u*y + v*x]

>>> convolution([u, v, x], [y, z], subset=True)
[u*y, u*z + v*y, x*y, x*z]

>>> convolution([u, v, x], [y, z], subset=True, cycle=3)
[u*y + x*z, u*z + v*y, x*y]

Plan for this phase has executed well, and the second evaluation has been successful.

Looking forward to the final phase of Coding Period.

July 13, 2018

At the start of the week I worked on the leftovers of week 8:

  • added log_singularities() that will help in determining logarithmic singularities,
  • improved documentation of all helpers as suggested by Amit to maintain consistency

Status of the PR’s:

PR #14736 is ready to be merged.

PR #14792 is being worked on. Major tasks has been completed, just review and refining has to be done.

Apart from this I started working on the way Lambert type equations can be solved through _transolve(). I looked into _tsolve's way of handling such equations. For solving Lambert type equations _tsolve() largely depends on It takes help of the different utility functions implemented there. Of them two important are _solve_lambert() and bivariate_type(). These two helpers help in getting the equations evaluated.

Equations that can be written in the standard form as: A + B*x + C*log(D + E*x) = 0 has the solutions in terms of Lambert function as:

D/E + C*B*W(t) with (B/C*E)*exp((BD - AE)/CE)

This is what _solve_lambert() determines and accordingly returns the solutions, otherwise returns a NotImplementedError

If _solve_lambert() is unable to handle bivariate_type() is tried. This function first tries to identify the type of composite bivariate and then substitutes Dummy in place of them. For eq: (x + y)**2 - 3 would become _u**2 - 3 where _u is the dummy variable. The idea is that solving the latter equation for u and then equating the solutions to the former equation is equivalent for solving the original one.

While implementing in _transolve this philosophy needs to be applied. As of now I have looked into different tests on how they behave. I will start implementing it next.

Next week’s plan:

  • Finishing with the logsolver

  • Implementing lambert solver.

July 11, 2018

July 08, 2018

Hello everyone. Here is the brief summary of the progress of rubi integration module in the 8th week of GSoC period.

We completed the testing of logarithmic test cases. Some of the tests are failing as they depend on trigonometric rules. The rules and tests have been updated in this PR.

Next, I loaded all trigonometric rules. They are huge in number. So the loading time increased from 1 min 30 sec to around 6 min. For now, I have not loaded them. I also updated the test cases for parsetools and fixed code quality issues. Currently, the travis is failing due to a bug, which has been fixed in branch 1.2. In the upcoming week, 1.2 probably will get merged in master.

Then I moved on to implementing appellf1 in sympy. Progress can be seen in this PR.

We will be updating our utility_functions to the latest version of RUBI.

Before the start of the week Amit and I discussed on a few points on:

Note: is_logarithmic() is an identifier helper for _transolve to determine whether the expression is logarithmic or not. and _solve_log() is a solving helper that returns the equation in a tractable form for solveset to better handle.

  • What should is_logarithmic() return?

While designing the method at first it returned a logcombined equation if found to be logarithmic, but we agreed upon having consistency among all the identifying helpers to return either True or False.

  • How _is_logarithmic() should work?

Next question was how it should work. We can implement it in two ways either to make the logcombined equation, if the expression reduces, it is obviously a logarithmic equation otherwise not. We also need to check whether the equation reduced has the variable to be solved in its free_symbols But logcombine possessed a problem that it unknowingly manipulates the equation, like log(x) - log(2*x) would reduce to log(1/2) for which the routine would return False as there are no symbol involved. So a more better way needs to be implemented.

  • How _solve_log() will handle removing unwanted solutions?

Simply reducing the logarithmic equation to a tractable form for solveset to handle would cause spurious solutions in the result. Therefore it becomes necessary to remove them. Take for example: solveset gives the result of log(x - 3) + log(x + 3) as {-sqrt(10), sqrt(10)}, but -sqrt(10) is not the solution in Real domain. Therefore one way to remove it was using checksol. Amit suggested on to have a look over the singularities and try incorporating the check in _solveset.

Things that I did during the week:

  • improved is_logarithmic()

Removed the logcombine way of checking the equation. As of now the _is_logarithm checks for every term to be logarithmic in terms of the variable to be solved, if so it returns True otherwise False

  • improved the _solve_log()

As per the current documentation of _transolve this routine is improved to return a modified form of the equation that solveset could better handle. Checking of the spurious solutions will take place in solveset itself.

  • Way to remove spurious solutions

To handle this scenario I have added a check in _solveset specifically for logarithmic equations to remove spurious solutions. The idea is based on the fact that natural log in undefined for negative and zero value, therefore this method gets each term of the expression, substitutes each solution to every term one by one and if for any term the value isn’t real that solution will not be included.

Why checksol() is not the appropriate way?

At first I thought of using the checksol(), but it possessed a problem. checksol unintensionally allows wrong solution to creep in. Take for example log(3*x) - log(-x + 1) - log(4*x + 1), solveset would give -1/2 and 1/2 as the solutions but the former isn’t a solution in real domain. Using checksol would not remove this as I*pi gets cancelled out during evaluating the expression therefore it returns True, which is not correct.

  • Addressing comments

Apart from this few changes have been done in the _transolve PR:

  • I have added a method that would return all the terms present in the expression: make_expr_args()

  • Made the expresssion remain unevaluated when doing lhs - rhs within _transolve.

Read this blog for better understanding of logarithmic solving.

July 07, 2018

This week I mainly focused on finding and solving a bug due to which continuum_mechanics gave ValueError on using units with the quantities passed. Initially, I created #14856, which included a workaround in the Beam class itself to handle that error. But Arihant suggested opening a separate PR as the error was occurring due to a bug in the separate module.

So, #14865 was created. is_commutative attribute was added in the Prefix class  (setting Prefix.is_commutative to True removed PolynomialError). While doing changes in the PR, another bug appeared:

>>> from sympy.physics.units import meter, newton, kilo
>>> from sympy.physics.units.util import quantity_simplify
>>> quantity_simplify(x*(8*newton + y))
x*(8*newton + y, 1)

This bug was solved with few changes. After #14865 gets merged, continuum_mechanics should work with quantities involving units.

Next Week

  • Make sure #14865 gets merged.
  • Open a Pull Request and start working on 3dbeam class.

July 06, 2018

This week I started working on adding Möbius Transform to the discrete module using Yate’s DP (Dynamic Programming) method for implementation as part of PR #14853. The proposed transforms are part of sympy.discrete.transforms module.

After discussing with Kalevi, the methods implementing this transform were added with appropriate names. The keyword subset is used as a boolean to choose whether enumeration is done over subsets or supersets. The usage for the transform is:

>>> from sympy import mobius_transform, inverse_mobius_transform
>>> seq = list(symbols('w x y z'))
>>> mobius_transform(seq)
[w, w + x, w + y, w + x + y + z]
>>> inverse_mobius_transform(_)
[w, x, y, z]
>>> inverse_mobius_transform(seq, subset=False)
[w - x - y + z, x - z, y - z, z]
>>> mobius_transform(_, subset=False)
[w, x, y, z]

The PR was merged successfully, after inclusion of docstring and unit tests for the transform.

Looking forward to another exciting week.

Older blog entries

Planet SymPy is made from the blogs of SymPy's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet SymPy with RSS, FOAF or OPML.