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
FriCAS gives "failed" because it currently can not compute
limit of 'erf'. You can work around such problem by
computing
--
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.
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