Skip to content
This repository has been archived by the owner on Sep 26, 2021. It is now read-only.

| possible Rubi ruleset implementation

Ralf Stephan edited this page Jun 18, 2018 · 1 revision

Motivation

The original Rubi implementation is in Mathematica. There is an attempt to do a Python implementation in SymPy. It uses the same approach as the original, i.e., a ruleset given in the form of pattern->expression pairs that relies on the CAS to sort it out. Consequently the CAS needs pattern matching capabilities on the level needed by Rubi. SymPy uses MatchPy, note however that MatchPy attempts to provide capabilities beyond those actually needed (e.g. Rubi uses practically no sequential variables like x___, and parallel matching may not be necessary for the task).

The philosophy behind using the same approach is centered on the idea that Rubi is essentially software---it is in flux, and Rubi updates need to be propagated to derived implementations, ideally as changes to the ruleset. From this perspective a ruleset-centric approach is natural. The alternative idea is that the Rubi ruleset is a form of knowledge, and the knowledge can be used in different ways. Moreover, the Rubi ruleset knowledge is in different states of flux, the central algebraic rulesets like 1.1.1.* are certainly crystallized now, while work seems to happen more on the periphery and other areas.

Types of implementations

The extensive Rubi testsuite is an ideal tool to determine the completeness of any implementation of the Rubi ruleset. There are however several degrees of conformity---an implementation might solve 100% of the testsuite, in the sense that

  1. each antiderivative solution, when differentiated, is provably equal to the integrated expression;

  2. each antiderivative solution, when differentiated, can be automatically proven equal to the integrated expression; this is usually done by applying the CAS's simplification function(s) to the difference of both and defining the zero outcome as success; the functions applied should be fixed beforehand;

  3. each antiderivative solution can be automatically proven equal to Rubi's solution; this solution is contained and readily available in the testsuite;

  4. each antiderivative solution can be automatically proven equal to Rubi's solution, and its complexity (expression tree size) is not greater than the one by Rubi;

  5. each antiderivative solution is identical to Rubi's solution, i.e., the difference is zero within the CAS, without simplification.

A type 2 implementation may be independent of attempting a type 5 implementation, but a type 3 implementation certainly is not, because the differences in expressions build up and are propagated from rules applied at the end of the computation to those applied at the start---no simplification can handle all possible changes, in fact, the needed simplifications are a great testsuite for the CAS themselves. With increasing expression complexity simplification may become the main test bottleneck, leading to another type of implementation:

  • 2x/3x/4x. success is on the condition that the computations of each test case may not exceed a predefined time (seconds)

With 3x/4x this condition (which is only practical) will force especially the complex solutions to be more similar to the respective solution by Rubi. With 2x it puts major importance on the CAS's simplification abilities---if they are difficult to improve then a type 2x implementation might even be impossible.