Fricas assumes parameters of integrated function to be non-zero, bug?

[Neven Sajko]

Consider the following:

f := cosh(a * x) * sinh(a * x)

integrate(f, x)

This results in an expression that is not a real number when the
parameter "a" equals
zero. But see:

g := cosh(0 * x) * sinh(0 * x)

integrate(g, x)

This on the other hand correctly computes the indefinite integral to be zero.

Consider a user (someone like me who is not intimately familiar with
the implementation
of FriCAS) who wants Fricas to integrate "cosh(a * x) * sinh(a * x)":
he or she will expect
the result of "integrate(f, x)" to be correct for any x, and indeed
there is no indication from
Fricas that this is not the case. Is Fricas's behavior thus not buggy?

Questions: Is this considered a bug by the developers? Is it just a
(temporary) limitation?
How tough would this be to fix, either by indicating the assumption of
"a" being non-zero
or computing for any parameter "a" right away?

Is there a way to tell which assumptions Fricas (in the integrate
function or elsewhere)
makes about parameters?

Is there already a way to force Fricas to integrate so that the
parameters can be any real
number, including zero?

Regards,
Neven

[Kurt Pagani]

Indefinite integrals make no sense without specifying types. However, you may
take the definite integral.

(1) -> integrate(f,x=u..v)

            a u 2   a v 4         a u 4        a v 2      a u 2
         (%e   ) (%e   )  + (- (%e   )  - 1)(%e   )  + (%e   )
   (1)  ------------------------------------------------------
                                 a u 2   a v 2
                          8 a (%e   ) (%e   )
                  Type: Union(f1: OrderedCompletion(Expression(Integer)),...)
(2) -> limit(%,a=0)

   (11)  0
                      Type: Union(OrderedCompletion(Expression(Integer)),...)
(2) ->


Better would be anyway (use functions (==) instead of Expression (:=))

(5) -> h(a,x)== cosh(a * x) * sinh(a * x)
                                                                   Type: Void
(6) -> integrate(h(a,x),x)
   Compiling function h with type (Variable(a), Variable(x)) ->
      Expression(Integer)

                 2            2
        sinh(a x)  + cosh(a x)
   (6)  -----------------------
                  4 a
                                         Type: Union(Expression(Integer),...)
(7) -> integrate(h(0,x),x)
   Compiling function h with type (NonNegativeInteger, Variable(x)) ->
      Expression(Integer)

   (7)  0
                                         Type: Union(Expression(Integer),...)


You certainly know from calculus that

(9) -> integral(f,x)

           x
         ++
   (9)   |   cosh(%A a)sinh(%A a)d%A
        ++
                                                    Type: Expression(Integer)

is not necessarily continuous in "a" ;)

[Waldek Hebisch]

Neven Sajko wrote:
>
> Consider the following:
>
> f := cosh(a * x) * sinh(a * x)
>
> integrate(f, x)
>
> This results in an expression that is not a real number when the
> parameter "a" equals
> zero. But see:
>
> g := cosh(0 * x) * sinh(0 * x)
>
> integrate(g, x)
>
> This on the other hand correctly computes the indefinite integral to be zero.
>
> Consider a user (someone like me who is not intimately familiar with
> the implementation
> of FriCAS) who wants Fricas to integrate "cosh(a * x) * sinh(a * x)":
> he or she will expect
> the result of "integrate(f, x)" to be correct for any x, and indeed
> there is no indication from
> Fricas that this is not the case. Is Fricas's behavior thus not buggy?
>
> Questions: Is this considered a bug by the developers? Is it just a
> (temporary) limitation?

Well, there is tendency to call any problem "bug". But if you
want to call it bug, it is more bug in mathematics (or in our
universe) than in FriCAS. Namely there are quite fundamental
problems related to to this. Since such questions are repeatedly
asked I created few FriCAS Wiki pages to explain the background:

http://fricas-wiki.math.uni.wroc.pl/DivisionByZeroDuringEvaluation
http://fricas-wiki.math.uni.wroc.pl/ConstantOfIntegration
http://fricas-wiki.math.uni.wroc.pl/NatureOfExpressions

> How tough would this be to fix, either by indicating the assumption of
> "a" being non-zero
> or computing for any parameter "a" right away?

Well, as explained in general simply plugging in parameters
may fail and there is no way to make this work in general, while
more complicated procedure like taking limits may work.
FriCAS probably could chose integration constant in a way
that minimizes chance of singularities.

> Is there a way to tell which assumptions Fricas (in the integrate
> function or elsewhere)
> makes about parameters?

During integration FriCAS assumes differential field. In
practice this means that FriCAS freely divides by things which
are not identically 0. For definite integration this is
not a problem: if the result is well-defined for given
parameter value, than this result can be obtained from
FriCAS result (possibly taking limits or similar).
For indefinite integration integration constant may have
extra singularity.

One extra remark: I think all CAS assume cooperation between
system and user. In FriCAS case system can do very good job
of finding indefinite integral. But user may wish to
transform this result to different form. Such transformations
are frequently goal oriented and user knowing goal can
do this better than unassisted FriCAS.

> Is there already a way to force Fricas to integrate so that the
> parameters can be any real
> number, including zero?

No. Note however that intersting (nonconstant) "unconditional"
functions have singularities. In general such singularity may
be real and inhibit evaluation. So to get total functions
you may need coditional definitions like "1/x for nonzero x,
0 for x = 0". Currently FriCAS does not support conditional
expressions... Of course, even assuming that conditional
expressions are supported we sill need code to generate
apropriate expressions.

--
Waldek Hebisch