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,245
Registered: 4/26/08
Re: now that the dust has settled ...
Posted: Oct 15, 2017 12:13 PM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply


clicliclic@freenet.de 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?
>


Meanwhile, a brief discussion at <http://sympy.narkive.com/qjikLL5W/
status-of-rubi-implementation-for-rubi> has shed some light on these
questions.

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.

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.