someone wrote:
>
> (126) -> integrate(cos(x)/x+exp(x),x)
>
> x
> 2%e + Ci(x) + Ci(- x)
> (126) ----------------------
> 2
>
> I'm a bit worried by the symmetrized Ci result,
> because according to definition of branch cuts
> this is only Ci(x) + i*pi/2. Of course the last
> factor is a constant ...
>
>
> We really need to have the new code tried earlier.
> I removed in "intpm.spad" the code for Si and Ci,
> but get unevaluated forms again:
>
> (1) -> integrate(sin(x)/x, x)
>
> x
> ++ sin(%A)
> (1) | ------- d%A
> ++ %A
> Type: Union(Expression(Integer),...)
> (2) -> integrate(sin(x)/x + exp(x), x)
>
> x
> (2) %e + Si(x)
> Type: Union(Expression(Integer),...)
>
> After a very quick test it seems to me that we
> maybe could already remove the "matcherfei" matcher.
Well, core integrator is 'lfintegrate' routine in 'intef.spad.pamphlet'.
'lfintegrate' first uses Risch algorithm to produce "integrable"
part and possible "nonintegrable" remainder. Then pattern
matcher is tried on the remainder. Risch integrator can only
handle functions of specific form. General Risch integrator
must have elementary functions written in terms of 'exp' and
'log'. It has incomplete support for primitives in the
integrand. There is also special part to handle integrands
containing unevaluated derivatives (the only way an expression
containing uniterpreted function can posses a symbolic integral
is to also contain unevaluated derivative of this functions and
the code should handle many such cases). There are one or two
tricks to handle general functions, but normally Risch integrator
will give up on nonelementary integrals. Risch integrator
needs to have all algebraic dependencies in explicit form:
transcendental functions must produce algebraically indpendent
results and algebraic extensions (in particular roots)
should be independent.
There is also special Risch integrator which handles functions
of single tangent. More precisely, functions of form R(x, t)
where R is a rational function in x and t and t is a tangent
of a rational function of x.
For users main entry to the integrator is via 'integrate' routine
in FSINT package (file 'integrat.spad.pamphlet'). 'integrate'
transforms integrand to the form expected by 'lfintegrate'
calls integration routine and then transforms the result
back to make it more readable. At the very begining
'integrate' passes to 'complexIntegrate' integrals
that can not be handled in real way. Then it
uses 'realLiouvillian' and 'rischNormalize' to
express integrand in terms of 'exp', 'log', 'tan' and 'atan'.
General case of integrands containing 'tan' or 'atan' is
converted to 'exp' and 'log' by introducing complex
coefficients. The result of integration is than converted
back to real function.
When there is single 'tan' and no other transcendentals or
algebraics then the integrand is handled without introducing
complex numbers by special Risch integrator. Of course,
if there are only 'exp'-s and 'log'-s there is no need for complex
numbers.
Now. coming back to problems you mention: pattern matchers for
Ci, Si, fresnelC and fresnelS work in terms of tangent. So
they are only used when function is to be handled by
special Risch integrator. The new 'Ei' routine works as
part of general Risch integrator and must see 'exp' to
work. I plan to pass all integands to general Risch
integrator. This can be done modifying the 'goComplex?'
in 'integrat.spad.pamphlet' to:
goComplex?(rt, l, ltan) ==
empty? ltan => rt
true
(the second line is changed). After that all trigonometric
functions will be expressed in terms of 'exp' and pattern
matchers looking for 'tan' will no longer work. Also,
integrals to trigonometric functions will change --
some log terms will get simpler while other will be
more complicated. There may be some other breakage since
we will take different codepath and lurking bugs will
have new opportunity to bite.
Next, currently trunk does not contains Risch extension
for 'erf' so pattern matcher for 'erf' definitely is
needed. For 'Ei' Risch code handles most cases, but
things like:
exp(exp(x))
exp(1/log(x))/(x*log(x))
go to pattern matcher. Similarly:
sin(1/x))/x
is handled by pattern matcher, but not by code in trunk.
So we need second part of extension in trunk before we
can retire pattern matchers.
Concerning the 'Ci(x) + Ci(-x)' part: this is due how
we handle convertion from complex result to real one.
More precisely, Risch integrator produces 'Ei' and I think
it should continue to do so. Namely, what Risch integrator
sees is subject to variuos transformations and Risch
integrator has too little information to decide betwieen
'Ei' and 'Ci + %i*Si'. Currently 'integrate' calls
'postSubst' routine to (partially) undo changes done
via 'realLiouvillian' and 'rischNormalize' and
convert result to real form. Convertion to real
form is done by calling the 'real' function from
'TrigonometricManipulations' package. However,
this is not right, we should have special purpose
function to rewrite integrals into real from.
For exmaple, in case you show Risch integrator
produces '(Ei(%i*x) + Ei(-%i*x))/2'. The 'real'
routine rewrite 'Ei(%i*x)' to 'Ci(x) + %i*Si(x)'
and 'Ei(-%i*x)' to 'Ci(-x) - %i*Si(x)'. The 'Si'
terms cancel and we get '(Ci(x) + Ci(-x))/2'.
Since 'Ci(x)' and 'Ci(-x)' differ the 'real'
routine can do nothing more. But in context
of integrator we know that we can drop constants,
so we could collapse this to 'Ci'. Some transformations
done by 'real' are unwanted, for example we would
like to have 'asin' in the answer if user gave
'asin' in the input, but 'real' transforms it to
'atan'. In some cases 'real' gives wrong result.
Namely, if the interand looks real but is in fact
complex we may get complex result which real may
mishandle (drop complex part). In some cases
'real' gives too complicated results: to correctly
compute real part we sometimes need to take square
roots. 'real' is not smart about this and may
introduce several dependent roots creating
really messy expressions. Also, 'real' can
not handle complicated nonelementary
expressions and signals errors in such case.
It will take some time to get good replacement for
'real' so for time beeing we have to live with
its drawbacks. I have commited to trunk code
to ignore errors in 'real' so ATM we somewhat
cover up one of its problems.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" 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 http://groups.google.com/group/fricas-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
