The Math Forum



Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.


Math Forum » Discussions » sci.math.* » sci.math.symbolic

Topic: now that the dust has settled ...
Replies: 4   Last Post: Oct 15, 2017 12:13 PM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
clicliclic@freenet.de

Posts: 1,239
Registered: 4/26/08
now that the dust has settled ...
Posted: Sep 15, 2017 12:32 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply


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?

Martin.



Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© The Math Forum at NCTM 1994-2017. All Rights Reserved.