Status of Rubi implementation for Rubi?

[Robert Dodier]

Hi, I see there's been a lot of messages about Rubi for SymPy, but I haven't been able to figure out how it turned out. Can someone briefly summarize the status of the Rubi implementation for SymPy and maybe point me to the code? The reason I ask is that a Rubi implementation for Maxima has been a long-standing wish list item ... I am hoping to get some inspiration from the SymPy version.

best,
Robert Dodier

[Robert Dodier]

Argh, I mean "for SymPy", of course.

[Francesco Bonazzi]

Hi,

the code for RUBI is here:
https://github.com/sympy/sympy/tree/master/sympy/integrals/rubi

We have been using MatchPy:
https://github.com/HPAC/matchpy

MatchPy provides an associative-commutative pattern matcher. Unfortunately it only supports Python 3.6.

We also have implementations for RUBI's utility functions and some of Mathematica's tree expressions:
https://github.com/sympy/sympy/blob/a7b29f5b464b76591bef97705486b87e0891ed53/sympy/integrals/rubi/utility_function.py

[Robert Dodier]

Hi Francesco, thanks for your response. The Rubi implementation looks very interesting, also the paper about matching algorithms. I will definitely take a close look at that.

What is your feeling about how the Rubi implementation turned out overall? Did you run into any roadblocks on the way? Do you think the general approach can be extended in a straightforward way to all of Rubi? If not, what are the large-scale changes that you foresee?

Is it known how the time required to process an expression with this implementation varies as a function of the number of rules? Is it known whether the time is linear in the number of rules, or perhaps logarithmic or something else?

Thanks for any remarks you might have on this subject.

best,
Robert Dodier

[Francesco Bonazzi]

On Saturday, 7 October 2017 12:30:16 UTC-4, Robert Dodier wrote:

Hi Francesco, thanks for your response. The Rubi implementation looks very interesting, also the paper about matching algorithms. I will definitely take a close look at that.

 Yes, the MatchPy authors have published a paper on Arxiv.

What is your feeling about how the Rubi implementation turned out overall? Did you run into any roadblocks on the way? Do you think the general approach can be extended in a straightforward way to all of Rubi? If not, what are the large-scale changes that you foresee?

Technically we have imported all of RUBI. Unfortunately there's still some work to do, as apparently some rules aren't properly matched. This is probably due to errors in the utility functions implementations and possibly to other factors leading to wrong matchings or processing of data.

We haven't had any thorough investigation about whether MatchPy is fully compatible with RUBI, the main possible problem being expressions matched by more than one rules (in MatchPy the matching rule could be different than in Mathematica).

 

Is it known how the time required to process an expression with this implementation varies as a function of the number of rules? Is it known whether the time is linear in the number of rules, or perhaps logarithmic or something else?

Using MatchPy seems to be slower than using the SymPy integrators. Our major problem now is the loading time for the rules (it's around one hour on my computer).

We have talked to the MatchPy developers and they have agreed to add a code generator to compile the rules into a decision tree. Unfortunately the size of the generated file is huge and more work is probably needed on the optimization of the generated code, but I feel like that's the right way to go.

Ideally, if MatchPy were able to generate an optimized decision-tree, then it would probably make the integration algorithm faster. I believe that's the way to proceed.

[Edward Montague]

  Is there a convenient way to track the progress of this .

  Albert.Rich has mentioned a version 5 of RUBI , that will use a
highly efficient , if ... then ... else structure . Is this the type of
structure that the new sympy , with matchpy , might generate .
 If so , how might it perform , relative to what's proposed for RUBI
5 .