firstname.lastname@example.org schrieb: > > 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? > > Do you know some of the answers? >
One learns in particular that using MatchPy on Rubi's rule set "seems to be slower" than using the present SymPy integrators. This sounds like MatchPy having been found uncomfortably but not prohibitively slow in this application. And patterns should be matched faster if conditions accompanying the rules can be evaluated during the matching process, not afterwards. I suppose this would have been difficult to test with MatchPy running in Python 3.6 where SymPy augmented by Rubi's utility functions cannot run.
The compatibility issue would become irrelevant if the equivalent Python code emitted by MatchPy could be executed in SymPy, but the size of the generated file is said to be "huge". This may mean either prohibitively huge, or again that the execution is just uncomfortably slow for a default integrator. Anyway, a better optimization of the code generated is said to be "probably needed". The belief is expressed that this would make Rubi on SymPy "faster", which may mean usably fast, but it remains unclear if work is foreseen in this direction and how long it is expected to take.
The long loading time mentioned in the GSoC reports amounts to "around one hour". Apparently, each time MatchPy is to be used on the Rubi rule set, its internal representation must be rebuilt by reading in all of the rules in Python syntax; no provision seems to be made in either Python or MatchPy to dump and reload the internal representation. One wonders why such a basic feature was considered unnecessary or too hard to implement for MatchPy, the more so since the long loading time was blamed for Rubi being not really usable on SymPy.
The "main possible problem" is mentioned that MatchPy wouldn't know what to return if multiple Rubi rules match a given expression. This doesn't look serious to me. If such ambiguities exist in Rubi's rule set, Mathematica would presumably apply the first matching rule, based on the order in which the rules were read in. This could be reproduced in MatchPy by recording the input order in the internal representation and providing a MatchFirstOccurence command that collapses multiple results accordingly. Or this could be implemented outside MatchPy by storing the sequential rule numbers along with the expressions to be returned.