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]
> <javascript:>> 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] <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/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/acccc683-ef70-4d64-a584-a8414d2ef19b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
