Definite integrals and real valued parameters.

37 views
Skip to first unread message

Yrogirg

unread,
Apr 8, 2011, 6:49:01 AM4/8/11
to FriCAS - computer algebra system
I need to find definite integrals of type

integrate(exp(-a*p^2),p = %minusInfinity..%plusInfinity)

for which FriCAS gives me "failed". Even

integrate(exp(-a^2*p^2),p = %minusInfinity..%plusInfinity)

fails, although integrate(exp(-a^2*p^2),p) works. How can I evaluate
the first integral (assuming a>0)?

Waldek Hebisch

unread,
Apr 8, 2011, 12:42:18 PM4/8/11
to fricas...@googlegroups.com

I am not sure what you really want. You presumably want some
different integral, because for this one you can simply use
the known value.

For the

integrate(exp(-a^2*p^2),p = %minusInfinity..%plusInfinity)

FriCAS gives "failed" because it currently can not compute
limit of 'erf'. You can work around such problem by
computing

(15) -> i := integrate(exp(-a^2*p^2),p = b..c)

+---+
(erf(a c) - erf(a b))\|%pi
(15) ---------------------------
2a
Type: Union(f1: OrderedCompletion(Expression(Integer)),...)
(16) -> eval(ii, [erf(a*c) = 1, erf(a*b) = 0])

+---+
\|%pi
(16) ------
2a
Type: Expression(Integer)

If FriCAS gives you back unevaluated indefinite integral this
(except for bugs) means that integral can not be done using
elementary functions. Some such integrals can be done using
"well-known" special functions (like erf above). Currently
FriCAS has quite limited capabilities for handling such
integrals. Basically FriCAS first tries to extract elementary
part and then tries to pattern-match the integral to some
known form. But pattern-matching frequetly is unreliable:
small change in integral causes match to fail. Also, small
change in form of integral may cause significant change to
the result. In your case using a instead of a^2 means that
result should contain square root, so needs different pattern
than case of 'a^2'.

If your integrals are related to known special functions it
may be possible to teach FriCAS about it like:

(18) -> intrule := rule integral(exp(-a*p^2),p) == sqrt(%pi)/sqrt(a)

p 2 +---+
++ - %A a \|%pi
(18) | %e d%A == ------
++ +-+
\|a
Type: RewriteRule(Integer,Integer,Expression(Integer))
(19) -> intrule integral(exp(-a*p^2),p)

+---+
\|%pi
(19) ------
+-+
\|a
Type: Expression(Integer)

Remarks:

- This is of little use if you have single integral to do. But you
can define more rules which together handle several integrals.
Also, rules can replace parts of expression.
- It is possible to define rules for indefinite integrals, but only
if limits are finite (limits have to be expressions, but %plusInfinity
is not an expression).

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Juan Jose Garcia-Ripoll

unread,
Apr 23, 2011, 4:16:34 AM4/23/11
to fricas...@googlegroups.com
El viernes 8 de abril de 2011 18:42:18 UTC+2, Waldek Hebisch escribió:

FriCAS gives "failed" because it currently can not compute
limit of 'erf'.   You can work around such problem by
computing

How difficult is it to "extend" FriCAS's knowledge base? I have found myself at trouble with various integrals, which after playing with Mathematica I learned they were defined in terms of some special functions. Is it hard to hook this knowledge back into FriCAS? Same goes for the erf limits and other knowledge about special functions (HypergeometricF, DawsonF, Ei, etc etc)

Juanjo 

Prof. Dr. Johannes Grabmeier

unread,
Apr 23, 2011, 4:46:08 AM4/23/11
to fricas...@googlegroups.com
AXIOM had once the first implementation of a decisive algorithm (Risch algorithm) to integrate elementary functions or prove that
no elementary integral exists. This is due to Barry Trager and Manuel Bronstein (the latter passed away too early 6 years ago)
Hence, there is not a thing like a "knowledge base" for integration, but a decision procedure.

Meanwhile other systems seemed to manage to "integrate" algorithmic and knowledge base approaches. The question is whether AXIOM wants to go the same way or to continue the algorithmic work of Bronstein? (cf. his book on Symbolic Intgeration Part I Transcendental functions).  Part II on algebraic functions will never be written.


--
You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
To post to this group, send email to fricas...@googlegroups.com.
To unsubscribe from this group, send email to fricas-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.

Mit freundlichen Grüßen

Johannes Grabmeier

Prof. Dr. Johannes Grabmeier
Köckstraße 1, D-94469 Deggendorf

Juan Jose Garcia-Ripoll

unread,
Apr 23, 2011, 7:16:06 AM4/23/11
to fricas...@googlegroups.com
I am not interested in algorithms per se, but in real use of the program. There exist special functions which are defined in terms of integrals (for instance erf), and which can be manipulated (differentiated, taylor series, numerical evaluation...) as if they were "elementary". In the real world, these are needed. My question, rephrased in order to avoid detours is, how difficult is it to incorporate new integrals into Axiom's inners, let it be knowledge base, decision table or whatever?

BTW, it does not seem true that Axiom is based solely on a decision process. From the manual it mentions explicitly the use of tables of integrals and it already provides functions such as erf() and the like, so definitely some work has been done that goes beyond elementary functions.

Juanjo

Waldek Hebisch

unread,
Apr 26, 2011, 1:47:10 PM4/26/11
to fricas...@googlegroups.com

Adding new special function to FriCAS is relatively easy: of order
of 10 lines of code + coding formula for derivatives (some
derivatives have big formulas). After that FriCAS can perform
"rational simplifications", compute derivatives, some Taylor
series (not nice) and some (easy) limits. To get better Taylor
series one have to add separate routine -- there are helper
routines to handle solutions of differential equations, so
typically this is not much work. Numerical evaluation needs
separate routine -- ATM several freshly added special functions
lack numerical evaluation. Most limits are done via expansion
into series, so can be done only having derivatives. But
"interesting" cases are based on asymptotic behaviour and
that needs to be coded on case by case basis. More precisely,
limits like erf at infinity are problematic because erf is not
analytic at infinity, so they need to be rewritten as limit
of different expression, such that singular part is elementary
and nonelementary part is analytic at infinity. Should be
not hard in principle but waits for for new limit routine
based on Gruntz algorithm (Gruntz algorithm is better than
our current algoritm at handling limits in essential
singularities).

The above is about adding new special functions representing
integrals. To actually get them as integration results needs
extensions to integrator.

Extending Risch algoritm is serious work. I can say more about
what is done in FriCAS (compared to Axiom) and about possible
future developements, but you are probably more interested in
easier ways.

Rich integrator actually decomposes functions into two pieces: one
that is can handle and other one which does not have elementary
integral. The second piece is sent to pattern-matching integrator.
Currently pattern-matching integrator has about 9 patterns.
Adding more in not hard, but currently tedious: existing code
uses 10-30 lines per pattern. I believe that the coding effort
can be substantially reduced using existing machinery of
rewrite rules, but only trying we can find out if this belif
is correct.

Another possiblity is adding Risch-Norman integrator. When
integrand is elementary than Risch-Norman is less capable
than Risch, but Risch-Norman can handle some non-elementary
integrands which are hard for extended Risch. Simple
version of Risch-Norman should be easy to do -- we already
have most of the code in existing integrator, and the
extra code probably will be of order of 50 lines. OTOH
to get reasonable speed on big integrals may require significantly
more work.

For a class definite integrals Mathematica and Maple use reduction
to MeijerG function. Simple version should be doable with limited
effort but production version is likely to take 1000-3000 lines
of code.

If main interest is to actually compute integrals (as opposed
to working on integrator), then probably adding patterns is
easy enough. But it also depends on which integrals one
wants: some integrals are easy for algorthms and hard for
patterns, some are hard for algorthms and easy for patterns.
And if integrals vary a lot then one may need a lot of patterns.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

Reply all
Reply to author
Forward
0 new messages