GSoC Idea: Rubi integrator

[Ondřej Čertík]

Hi,

Here is a project that I would love to see happen:

https://github.com/sympy/sympy/issues/12233

I am available to mentor it, and I think quite a few people are
excited about it and such a system/framework (i.e. set of rules for
patter matching + compiler to generate a fast if/then/else decision
tree) would have applications beyond just integration, but integration
would already be super useful. As you can browse on Rubi web page, the
integrator's capabilities are very impressive, i.e. the rule based
system Rubi 4.9 can do more integrals than Mathematica, and is about
as fast, due to the large number of rules, and the if/then/else
decision tree Rubi 5 promises an order of magnitude (or more) speedup,
but it's still in development.

The project is big in scope, so there could even be multiple projects.
If anybody is interested in this, please get in touch, and try to
propose a good plan.

Ondrej

[Abdullah Javed Nesar]

Hi Ondřej,

I am willing to work on Rubi Integrator this summer. I went through the issues you raised for this project and this idea really sounds cool. It would be great to segregate the different methods of integration into a decision tree which would hence improve its performance. 

Before implementing Rule-based integrator we need to implement fast pattern matching/replacement for the set of 10,000 rules so we need to plan out an efficient decision tree for it. 

log(x*y) -> log(x) + log(y);   x > 0, y > 0

In the above example how do we exactly move on with domain restrictions (i.e. x, y).

[Aaron Meurer]

The SymPy assumptions system lets you define x = Symbol('x',
positive=True) (and query like x.is_positive). The pattern matcher
will need to be able to set and define restrictions like this. Also
note that expand_log() and logcombine() already expand and combine
logarithms and check the domain restrictions.

Another thing is that the integrator should return a Piecewise
whenever possible. For example, the current integrator:

In [6]: integrate(x**n, x)
Out[6]:
⎧log(x) for n = -1
⎪
⎪ n + 1
⎨x
⎪────── otherwise
⎪n + 1
⎩

This way we get results that are mathematically correct, even when
assumptions aren't set.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/05a4ee3e-7a0b-485b-9918-0a68bb4f3350%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Abdullah Javed Nesar]

Hi Aaron,

Thanks for your explanation.

How does SymPy evaluates integrals like,

>>integrate((a + b*u)**m, x) when u = c + dx  (i.e. Integration by substitution)

I couldn't find such an example can give one?

Abdullah Javed Nesar

[Aaron Meurer]

integrate() uses several algorithms, and one or more algorithms may
apply to any specific integral. Some algorithms, if you know how they
work, you can easily see if they won't apply to a specific integrand.
The best way to tell how it works for a specific integral is to check
the various algorithms. Another thing that I highly suggest is to run
the integrate() function through a debugger, so you can see how it
works (I like PuDB, but any debugger that you are comfortable with
will work).

Here are the algorithms used by integrate() (I hope I didn't forget
any). You can import each algorithm from the specified module to try
it

sympy.integrals.risch.risch_integrate() - Risch algorithm. Currently
only works for transcendental equations with exp() and log().

sympy.integrals.manualintegrate.manualintegrate() - Manual
integration. That means, integration akin to how you would do things
by hand. This is very similar to Rubi in that it does pattern matching
against some rules. Ideally any implementation of Rubi would merge
with manualintegrate() so we don't have two pattern matching
integrators.

sympy.integrals.trigonometry.trigintegrate() - Integrate trig
functions. Also uses pattern matching.

sympy.integrals.rationaltools.ratint() - Integrate rational functions.

sympy.integrals.meijerint.meijerg_definite() and
sympy.integrals.meijerint.meijerg_indefinite() - Integration using the
Meijer G algorithm (roughly, by translating the integral to a Meijer
G-function, integrating, then translating back).

sympy.integrals.heurisch.heurisch() - The heuristic Risch algorithm.
This is tried last, because it can be very slow (sometimes hanging the
integrator), but there are cases where only it can produce an answer.

You should be able to apply any of these functions directly on an
integrand to see if they can produce an answer.

The algorithms are tried in order until one gives an answer. I don't
remember exactly what order, but I think it's similar to the above. I
do know that heurisch() is last, because it's the worst.

Aaron Meurer


On Sun, Mar 5, 2017 at 12:00 PM, Abdullah Javed Nesar

> https://groups.google.com/d/msgid/sympy/0cc84418-0eac-4ab2-b975-c74eeec47d64%40googlegroups.com.

[Abdullah Javed Nesar]

Hi,

I was looking into sympy.integrals.manualintegrate.py it seems that the pattern matching (in manualintegrate) is quite different from what is expected in Rubi. As PR #7748 mentions we'll be using a better approach using decision tree, can you elaborate on what is expected? How decision tree concludes to a rule of integration then falls into function integrate() which contains rules like 1.1.1 (a + b*x)**m?

Abdullah Javed Nesar 

[Arihant Parsoya]

Hi, 

I observed that rules in manualintegrate() are countable in number. While implementing ~7000 rules, naming each rule is also going to be a big issue. I was thinking, names should be given based on the serial number of the rule in Rubi website. For example algebric rules for linear products should be named as:

>>> def rule_algebric_integrand_1_1_1_1(expr, symbol):

...     return log(expr)

Using the above syntax for names of rules, we will be able to uniquely identify each rule. Is this desirable?

Thanks,

Arihant Parsoya

[Aaron Meurer]

That's sounds fine, though it should also include a docstring that lists the rule so we don't have to depend on the Rubi site. This will also let us generate some documentation on what rules are supported. 

We will likely want to extend the rules beyond what Rubi has eventually, so we should also consider that. 

Aaron Meurer 

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/8efee19b-fedd-4188-b00f-e68ecf288eb5%40googlegroups.com.

[Arihant Parsoya]

Thanks Aaron,

I read the discussion to improve pattern matching algorithm. Can you give some information about which algorithm is currently being used for pattern matching? 

I have been testing `match()` to check if it works properly for complex expressions. It gives correct answer if we `exclude` the integration variable. However, there can be issues in matching expression when brackets are automatically evaluated by SymPy:

>>> x, y, z, F, fx = symbols('x, y, z, F, fx')

>>> a = Wild('a', exclude=[x])

>>> b = Wild('b', exclude=[x])

>>> c = Wild('c', exclude=[x])

>>> d = Wild('d', exclude=[x])

>>> e = Wild('e', exclude=[x])

>>> f = Wild('f', exclude=[x])

>>> g = Wild('g', exclude=[x])

>>> p = Wild('p', exclude=[x])

>>> n = Wild('n', exclude=[x])

>>> m = Wild('m', exclude=[x])

>>> expr = ((1 + 2*x)**3) * ((F**(4*(5 + fx)))**6) * (6 + 7*(F**(4*(5 + fx))))**8

>>> pattern = ((c + d*x)**m) * ((F**(g*(e + fx)))**n) * (a + b*(F**(g*(e + fx))))**p

>>> pprint(pattern)

                   p                         n

⎛ g⋅(fx + e)      ⎞           m ⎛ g⋅(fx + e)⎞ 

⎝F          ⋅b + a⎠ ⋅(x⋅d + c) ⋅⎝F          ⎠ 

>>> pprint(expr)

                               8           

 24⋅fx + 120 ⎛   4⋅fx + 20    ⎞           3

F           ⋅⎝7⋅F          + 6⎠ ⋅(2⋅x + 1) 

>>> expr.match(pattern)

{p_: 1, g_: 1, m_: 3, d_: 2, n_: 0, e_: 23*fx + 120, c_: 1, a_: 0, b_: (7*F**(4*fx + 20) + 6)**8}

We need to find a way to convert the expresison into known standard form so pattern matching can be done peoperly or implement such functionality in `.match()` itself.

Thanks

[Abdullah Javed Nesar]

Hi,

Arihant thanks for those suggestions, I guess if rule name contains Algebraic then just

>>> def rule_algebraic_integrand_1_1(expr, symbol)

would suffice, no need for >>>def rule_algebraic_integrand_1_1_1_1(expr, symbol)  (indicating algebraic integrand>linear product>(a + b*x)**m). Yes, this way the functions would be named in a systematic way, necessarily supported by a docstring which would explain those rules in details, as Aaron pointed.

Pattern matching used in manualintegrate() is a simple one without a decision tree and hence less efficient. The tree for (a + b*x)**m would be better represented as

 Pow(Add(a, Mul(b, x)), m), well explained in #7748.

[Abdullah Javed Nesar]

Hi,

I am not able to figure out how exactly we will use replacement allowing technique in Rubi and when do we use it, can anyone explain this?

Thanks.

[Aaron Meurer]

Can you clarify what you mean by this?

Aaron Meurer 

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/6e64ae8e-2c19-49ca-9d74-fb873ac77112%40googlegroups.com.

[Abdullah Javed Nesar]

Aaron in case like this,

>>> integrate(E**(n*log(a+b*x)), x)

⎧⎩⎨1blog(ab+x)abn+benlog(a+bx)+bxbn+benlog(a+bx)forn=−1otherwise

E**(n*log(a+b*x))should better be simplified to (a+b*x)**n to proceed further, can you tell me how SymPy currently handles such cases?

Abdullah Javed Nesar

[Aaron Meurer]

I recommend using the method I outlined above to figure out which
algorithm is actually handling this. Or just run integrate() through a
debugger.

For the pattern matching integrator, there is a discussion in another
thread here on how to make patterns match expressions that are
mathematically equivalent, but don't match exactly.

Aaron Meurer

On Fri, Mar 10, 2017 at 9:05 AM, Abdullah Javed Nesar

> https://groups.google.com/d/msgid/sympy/2d53f1c8-52b3-4a0a-89af-bf70d83d4df1%40googlegroups.com.

[Richard Fateman]

There is a version of Albert Rich's project that

uses if-then-else   rather than a rule set.

Writing a pattern matcher that mimicks Mathematica's pattern

matcher would be irrelevant if you used that alternative.

On the other hand, mimicking Mathematica might have other

uses.  There are at least 2 in the open source; one in Lisp,

which I wrote, and another in the Mathics project, written in

python (!)

RJF

[Aaron Meurer]

On Fri, Mar 10, 2017 at 7:31 PM, Richard Fateman <fat...@gmail.com> wrote:
> There is a version of Albert Rich's project that
> uses if-then-else rather than a rule set.

I'm unclear, how do you have if-then-else that isn't pattern matching?
If you have some input expression, say (1 + 2*x)**n you have to know
if it looks like a given rule (in this case, (a + b*x)**n) , and what
the various constants are (a = 1, b = 2, n = n) to apply it. So you
have to pattern match it one way or the other. But maybe I'm missing
something.

>
> Writing a pattern matcher that mimicks Mathematica's pattern
> matcher would be irrelevant if you used that alternative.
>
> On the other hand, mimicking Mathematica might have other
> uses. There are at least 2 in the open source; one in Lisp,
> which I wrote, and another in the Mathics project, written in
> python (!)

Mathics uses SymPy as the symbolic backend. So that is an interesting
idea. It is currently licensed incompatibly (GPL). We might want to
ask the author (Angus Griffith) if he would be willing to relicense
the matching code (assuming it is something that can be easily reused
for SymPy).

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/65969745-6320-4861-b193-b7844e00c8f8%40googlegroups.com.

[Angus Griffith]

Hi Sympy people,

I'd love to help out on this. The stuff I've written in Mathics I'm happy to relicense under BSD for Sympy and I can certainly give guidance for working with Mathics too.

I've contributed to the pattern matcher but I'm not the original author of most of that code so we'll need to get approval from Jan and a couple others as well.

The Mathics pattern matcher might be useful to study but I'm worried about the performance on 10000 integration rules. Mathics will try each rule in turn until it finds a match.

The most useful parts of Mathics for this would be the parser and the to/from Sympy converters. Both of these should be simple to relicense but maybe that's not even needed and you can use Mathics as a compiler.

[Abdullah Javed Nesar]

Hi Angus,

Thanks for your willingness to help. Although I'm not familiar with Mathics, can you briefly explain the algorithm used for pattern matching in Mathics.

Abdullah Javed Nesar 

[Abdullah Javed Nesar]

Hi,

Thanks Aaron for your reply, that really helped. I think I've collected sufficient information about the project and I'll need your help to complete my proposal and organize tasks better.

I think framing of rules is lengthy but quite straightforward. Pattern matching which needs to be implemented prior to it is where I need your help. I was looking at Francesco Bonazzi's proposal on new pattern matching and it seems fine to me. Do we need to add anything more to it or improve on anything? What do you think?

Abdullah Javed Nesar

[Aaron Meurer]

Starting with Francesco's work is a good idea. He has thought about
pattern matching in SymPy more than anyone else.

Aaron Meurer

On Mon, Mar 13, 2017 at 2:48 PM, Abdullah Javed Nesar

> https://groups.google.com/d/msgid/sympy/06665b8f-9e0e-4231-8032-1610a9c01072%40googlegroups.com.

[Arihant Parsoya]

Hi Aaron, 

I think documentation of all the rules implemented is important(as mentioned by Ondrej). I was thinking to implement automatic documentation of rules in the decision tree using abstract syntax trees. AST automatically converts all `elif` and `else` conditions to `if`s. We can write a program which automatically generates documentation of rules with their conditions using AST. Is this a good idea?

Thanks

[Aaron Meurer]

If we structure the rules properly, it shouldn't be necessary to parse Python.

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/a533e5e6-80f0-4f28-a75d-a328ea71b5a8%40googlegroups.com.

[Arihant Parsoya]

Thanks Aaron. 

In manualintegrate, each rules is defined as seperate function whereas if we see Ondrej's PR #8036, the rules in decision tree are implemented directly. I am skeptical about which approach is better. I think, implementing rules as seperate functions can help us document the functions as well as. But on the other hand, it makes implementation lengthy. What do you think is the right way to go about it?

Thanks

[Aaron Meurer]

The rules should definitely be structured in some way that we can pull
them all out for documentation and other purposes. Whether that means
functions or some other data structure I don't know.

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/19c6d552-f14f-41d3-af9f-4e6ab723559f%40googlegroups.com.

[Aaron Meurer]

Also, I think the giant if-else chains in Ondrej's branch are very
unmaintainable. We can definitely structure the rules in a way that
makes the easier to read, document, and maintain.

If we treat it as a compiled output from some script that converts
rules from Rubi, then we can never modify it directly. But if we build
a nice pattern matching integrator, I think we will eventually want to
be able to add our own rules, beyond what Rubi has. We may also find
bugs in it, which we will want to be able to fix without having to
modify Rubi first. Since Rubi only has one maintainer and doesn't have
a public source repo (correct me if I am wrong), this worries me quite
a bit.

Aaron Meurer

[Ankit]

Hello Aaron,

I too was unsure about large scale implementation of giant if-else chains as you mentioned. However, I have the following setup in mind, and am trying to implement that.

As for my current understanding of a Rubi integrator, on a small scale, I use a Pattern matching algorithm, to match the pattern of expression and when one found, simply pass the parameters to already defined functions as that in https://github.com/sympy/sympy/pull/8036/commits/5e5208e8c14d1953e13267a4f1b91b701904e003#diff-2bc19e12c496825694e36430bcc2fcdbR11 .  

This approach can be used in following steps. One can work on defining functions, that would generate rules based result, and a pattern matching algorithm, that does the matching part, for respective functions. Then. both parts, can be combined (distributing these pattern matchers in categories,using if else approach,for different integration formula), to generate the result. 

Kindly let me know if you have any suggestions on this approach (any point that I should take care of). Also, where do you think, this approach could be affected performance wise? 

Thanks,

Ankit

.

[Francesco Bonazzi]

Concerning the pattern matching rules, it would be great if Mathics were able to relicense the relevant part of the code under a BSD license. In such a case, we would be able to re-use their code.

Also, if anyone is experienced with LISP, one could also try to translate the open source code by Richard Fateman into python, which essentially provides Mathematica-like compatibility functions.

Anyways, this is how I would proceed with the RUBI ruleset:

1. Generate an enormous amount of reasonable simple matching rules. This matching rules have to outnumber by far the rules in the RUBI set. Ideally, they can be randomly derived by RUBI's ruleset.
2. Given a large test set of integrand expressions, for each rules count how many of these expressions are matched.
3. Convert the number array of point 2 to a 2-state entropy.
4. Take the rule with the highest entropy and use it as the base if-clause.
5. For each branch in the decision tree, select the rule that maximizes the information gain.
6. Repeat point 5 until all branches lead to a single rule.

I think that scikit-learn could be used in the generating process, though I would try to do all these steps in Wolfram Mathematica.

[Abdullah Javed Nesar]

Hi,

Adding new rules would surely add on to Rubi's usability, we can handles a larger number of cases. Side by side care should always be taken to modify the if-then-else tree which is root of Rubi's performance.

I think the way Francesco presents seems good to me. What do you people think?

if expr.is_Pow:
    b1 = expr.base
    m = expr.exp
    ...

    if b1.match(a + b*x):
        a = ...
        b = ...
        ...
        if not a.has(x):
            ...
            if not b.has(x):
                ...
                if m != -1: 

return (a+b*x)**(m+1)/(b*(m+1)) 

although this seems to be a basic outline and can be organised better.

Abdullah Javed Nesar

[Abdullah Javed Nesar]

Hi,

I was looking at the proposal for new pattern matching, here how to use WildNode and WildSequence?

Abdullah Javed Nesar 

&

[Richard Fateman]

TLDR.

1. The difference between an if-then-else tree and "pattern matching"

is two-fold.

 (a) The "pattern matching" is probably referring to a purely rule-driven

algorithm, where each time there is a transformation, the rule set is

re-applied again.   A clever system will only look at the rules that are

(probably) applicable, but starting with thousands of rules can be

time-consuming.

(b) The if-then-else tree does use a local kind of pattern matching,

but this may actually be programmed as segmenting of an expression.

For example, you know that you got to a place in the program because

there is something of the form  W^Z.  Pick off the Z and --- if Z is

an integer then do P1  else do P2.      Where P1 and P2 are if-then-else...

So is this pattern matching?  Sort of.  Depends on how you pick off

pieces. e.g,  e=part(S,2)   or   match(S, b^e).

If your match program is simple enough, it could be about as fast.

If your match program is hairy like Mathematica's not so much.

2. A program that automatically converts rule-sets to if-then-else is

presumably what Albert Rich has done, and probably could be done

every time the rule set changes.  I suppose the target could be a sympy

compatible if-then-else tree,  since he apparently already targets

Maxima and Maple.

3. Rewriting the Lisp code for MockMMA in python is presumably something

that could be done.  I am available if someone needs to ask a question.

However, the person should obviously know Common Lisp as well as

Mathematica.  I am personally only superficially familiar with python.

There may be reasons other than Rubi to do this.  For example, if

you do a good job of this (a parser+enough semantics to

mimick the user-programming level of the language, currently

called "The Wolfram Language")  you could snarf down huge

piles of "application" code -- at least at some superficial level --

and then cut in the sympy alternatives as necessary for the

application,.

[Richard Fateman]

.. I said

....  you could snarf down huge

piles of "application" code -- at least at some superficial level --

and then cut in the sympy alternatives as necessary for the

application,.

which is what Mathics might do, if my understanding of the

documentation is correct.  I have not tried it.

Oh, since Mathics pattern matcher looks like it is (intending to)

implement Mathematica, including backtracking, it may be

susceptible to being very slow for patterns involving, for example,

+  and * .

RJF 

[Abdullah Javed Nesar]

Hi Aaron,

I find srepr in SymPy a powerful tool and can be applied in many ways to compare and traverse expressions and subexpressions in a tree.

>>> x = Symbol('x')
>>> a = Symbol('a')
>>> b = Symbol('b')
>>> m = Symbol('m')
>>> expr = (a + b*x)**m
>>> srepr(expr)
"Pow(Add(Symbol('a'), Mul(Symbol('b'), Symbol('x'))), Symbol('m'))"
>>> expr.args
(Add(Symbol('a'), Mul(Symbol('b'), Symbol('x', positive=True))), Symbol('m'))
>>> expr.args[1]
Symbol('m')
>>> expr.args[0]
Add(Symbol('a'), Mul(Symbol('b'), Symbol('x', positive=True)))
>>> expr.args[0]
Add(Symbol('a'), Mul(Symbol('b'), Symbol('x', positive=True)))
>>> expr.args[0].args
(Symbol('a'), Mul(Symbol('b'), Symbol('x', positive=True)))
>>> expr.args[0].args[1]
Mul(Symbol('b'), Symbol('x', positive=True))

[Abdullah Javed Nesar]

Hi everyone,

I have proposed a rough draft on Rubi Integrator here. This is not complete yet, I wish if anyone could suggest on its improvement or something I've missed. Much of it is referred from Francesco's proposal and  Mathematica.

Abdullah Javed Nesar

On Wednesday, March 15, 2017 at 4:06:51 AM UTC+5:30, Francesco Bonazzi wrote:

&

[Francesco Bonazzi]

On Sunday, 19 March 2017 20:51:43 UTC+1, Abdullah Javed Nesar wrote:

Hi everyone,

I have proposed a rough draft on Rubi Integrator here. This is not complete yet, I wish if anyone could suggest on its improvement or something I've missed. Much of it is referred from Francesco's proposal and  Mathematica.

I wrote that proposal 2-3 years ago. I think that pattern is a bit too cumbersome. I will try to update the proposal as soon as possible.

[Abdullah Javed Nesar]

Thanks Francesco, I was thinking it would be better if we propose Multiple Pattern to return the matched pattern number also, this way: 

>>> match(f(x), [f(wn1), wn2(wn1)])
{matched: 0, wn1: x}                 

Application:

type = match(Expr, [((a + b*x)**m), ((b*x)**m)])
        if type[matched] == 1:
            a = 0
        if (m == -1):
            return log(a + b*x)/b ...

[Francesco Bonazzi]

I have just converted the RUBI rules in an easily parseable format:

https://raw.githubusercontent.com/Upabjojr/RUBI_integration_rules/master/RUBI_DownValues_FullForm.txt

[Abdullah Javed Nesar]

Hi,

Francesco, the Proposal you've edited, is it final?

I was looking at some transformation rules in mathematica here, I think some of them may be helpful if implemented. Other references rules and definitions, manipulation of transformation rules. I need suggestions here?

Thanks!

Abdullah Javed Nesar

[Arihant Parsoya]

Hi,

    I have written my GSoC proposal here. Please give your feeback so I can improve on it.

Regards,

Arihant Parsoya

[Aaron Meurer]

Can you give more details on how the Pattern object would implement
partitioning?

For the timeline, I think once you have the pattern matching working,
and the infrastructure set up for the integrator, adding rules will be
easy. So it doesn't make sense to me to split up the weeks by which
rules will be implemented. I suspect a lot of time will be spent
working on the pattern matcher, then on setting up the integrator,
then implementing the rules. When the rules are being implemented, you
will likely find deficiencies in the pattern matcher or in the
integrator and they will need to be adjusted.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sympy.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sympy/d0668734-eec5-47e2-a79b-94c00b49d0f5%40googlegroups.com.

[Abdullah Javed Nesar]

Hi Aaron,

I have shared my proposal link in the GSoC website can you please have a look.

Thanks,

Abdullah Javed Nesar

[Aaron Meurer]

I would be careful doing things like log(x*y) => log(x) + log(y).
Without the proper assumptions on x and y, the expansion can be wrong,
which means it could lead to a wrong answer from the integrator. In
the example you give, the expansion will happen if a has the correct
assumptions:

>>> a = symbols('a', positive=True)
>>> b, x = symbols('b x')
>>> expand_log(log(a*b*x))
log(a) + log(b*x)

Also, you don't have a timeline yet (I guess you know this).

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/ad4adb24-0352-4b59-a393-86dfca59373b%40googlegroups.com.

[Abdullah Javed Nesar]

Thanks Aaron,

I'll correct that. Yes, timeline is yet to do. I'm not sure how much time to give on Pattern Matching, I think we can't just allot a particular period for it although initially matcher preparation will take time but, later too we need to keep modifying it.

Abdullah Javed Nesar

[Ondřej Čertík]

Hi Abdullah,

I read through your proposal, do I understand it correctly, that in
the first part of the project you want to use our current pattern
matching (or possibly improve it if needed) to represent the Rubi
rules, and that by itself should work? And then in the second part of
your project implement the compiler to the if/then/else form?

Ondrej

On Wed, Mar 29, 2017 at 2:09 PM, Abdullah Javed Nesar

> https://groups.google.com/d/msgid/sympy/6b4302ed-a289-4642-8a11-dd92af029c9e%40googlegroups.com.

[Abdullah Javed Nesar]

Hi Ondrej,

Yah exactly, for the first part of the project we'll possibly rewrite the matcher somewhat similar to as explained in #7748. But, I think we have to keep on working on it and modifying it as we move on with the second part.

You may have look at the PR #12407, where I have shown how we will be implementing rules and designing rubi_integrate() keeping in mind all possible conditions.

Abdullah Javed Nesar

[Ondřej Čertík]

On Thu, Mar 30, 2017 at 4:25 AM, Abdullah Javed Nesar
<abdulja...@gmail.com> wrote:
> Hi Ondrej,
>
> Yah exactly, for the first part of the project we'll possibly rewrite the
> matcher somewhat similar to as explained in #7748. But, I think we have to
> keep on working on it and modifying it as we move on with the second part.
>
> You may have look at the PR #12407, where I have shown how we will be
> implementing rules and designing rubi_integrate() keeping in mind all
> possible conditions.

Perfect, thanks! That looks good.

Just a note, as usual, that there might be more students applying for
the given idea (Rubi in this case), and just worry about your
proposal, outline how you think it should be done and what you want to
do. And then if more proposals are accepted for GSoC that overlap, we
will work with both accepted students to amend the work, so that both
projects are complementary.

Ondrej

> https://groups.google.com/d/msgid/sympy/5dcde756-d844-4aae-a44f-ec5db0f20c31%40googlegroups.com.

[Abdullah Javed Nesar]

Thanks! Ondrej,

I'll try to cover those points once I'm done with the timeline.

Abdullah Javed Nesar