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 <https://github.com/sympy/sympy/issues/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 <http://www.apmaths.uwo.ca/~arich/IntegrationRules/PortableDocumentFiles/1%20Algebraic%20functions/1%20Linear%20products/1.1%20(a+b%20x)%5Em.pdf> ?
Abdullah Javed Nesar On Monday, March 6, 2017 at 2:59:38 AM UTC+5:30, Aaron Meurer wrote: > > 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 > <[email protected] <javascript:>> wrote: > > 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 > > > > On Sunday, March 5, 2017 at 11:58:20 AM UTC+5:30, Aaron Meurer wrote: > >> > >> 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 > >> > >> On Thu, Mar 2, 2017 at 8:56 AM, Abdullah Javed Nesar > >> <[email protected]> wrote: > >> > 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). > >> > > >> > On Wednesday, March 1, 2017 at 8:39:41 PM UTC+5:30, Ondřej Čertík > wrote: > >> >> > >> >> 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 > >> > > >> > -- > >> > 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 [email protected]. > >> > To post to this group, send email to [email protected]. > >> > 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. > > > > -- > > 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 [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > 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/0cc84418-0eac-4ab2-b975-c74eeec47d64%40googlegroups.com. > > > > > > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/2206b394-2098-45f1-83d3-4964b3ca034f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
