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 <https://github.com/sympy/sympy/issues/7748>. On Thursday, March 9, 2017 at 3:36:30 PM UTC+5:30, Arihant Parsoya wrote: > > Thanks Aaron, > > I read the discussion <https://github.com/sympy/sympy/issues/7748> 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 > > > > On Thursday, March 9, 2017 at 12:16:41 AM UTC+5:30, Aaron Meurer wrote: >> >> 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 >> >> On Wed, Mar 8, 2017 at 12:07 PM Arihant Parsoya <[email protected]> >> wrote: >> >>> 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 >>> <http://www.apmaths.uwo.ca/%7Earich/IntegrationRules/PortableDocumentFiles/PortableDocumentFiles.html> >>> >>> website. For example algebric rules for linear products >>> <http://www.apmaths.uwo.ca/%7Earich/IntegrationRules/PortableDocumentFiles/1%20Algebraic%20functions/1%20Linear%20products/1.1%20(a+b%20x)%5Em.pdf> >>> >>> 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 >>> >>> On Monday, March 6, 2017 at 10:44:41 PM UTC+5:30, Abdullah Javed Nesar >>> wrote: >>>> >>>> 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]> 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]. >>>>> > 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/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/8efee19b-fedd-4188-b00f-e68ecf288eb5%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/sympy/8efee19b-fedd-4188-b00f-e68ecf288eb5%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> 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/2d630a6a-15da-42fb-9221-860fe7912307%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
