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. On Thursday, March 9, 2017 at 9:47:10 PM UTC+5:30, Abdullah Javed Nesar wrote: > > 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/6e64ae8e-2c19-49ca-9d74-fb873ac77112%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
