This year's GSoC (Google Summer of Code) season is over, the dust should have settled, and the results can be evaluated. Two of the GSoC students have been working on porting Rubi to SymPy, and their project reports are found on <http://planet.sympy.org>. Perhaps somebody reading this post has already formed an opinion of what has been achieved ...
What the reports tell:
- A pattern matcher with the required properties was found and adopted: MatchPy, written in Python, with some features indispensible for Rubi specially added on request.
- Apparently, MatchPy relies on Python version 3.6 and also depends on some third-party code, making it incompatible with the current SymPy system.
- All of Rubi's rules have been converted to be read by MatchPy, which can then either respond to matching queries directly, or emit Python code that performs the matching.
- Of Rubi's utility functions, which are needed to actually apply the integration rules, all but a handful have been converted to SymPy, the widely used Dist function being among the missing ones.
- Because pattern matching via MatchPy turned out to be slow and some utility functions are still missing, Rubi in Sympy could not be tested extensively.
Some questions are obvious:
- Can't the missing utility functions be implemented satisfactorily on the basis of SymPy's current symbolic capabilities?
- The resulting Rubi in Sympy is said to be "not really usable" in view of its long loading time. How long roughly? Is the evaluation of each integral affected individually, or even every matching step?
- Would the execution speed of Rubi in SymPy become acceptable (say below one minute per integral) if MatchPy were rewritten to make it (or the code it produces) compatible with Sympy?
- Are there such plans to incorporate MatchPy into the SymPy system? Roughly how many person-months is this expected to take? Perhaps MatchPy should better be rewritten in C?