Evaluate Integral

[Dario Beraldi]

Hello,

I have the function fx for which I want to evaluate the indefinite integral:

x= symbols('x')
fx= (sin(4*x) - sin(2*x)) / (cos(3*x))
i= integrate(fx)
print i
## Integral((-sin(2*x) + sin(4*x))/cos(3*x), x)

Now, how can I evaluate i to obtain the "expected" -2*cos(x) + c as per here http://www.wolframalpha.com/input/?i=integrate%28%28sin%284*x%29+-+sin%282*x%29%29+%2F+%28cos%283*x%29%29%29

I tried i.evalf(), i.doit() with no luck.

Again, many thanks for help!

Dario

[Francesco Bonazzi]

I guess the algorithm is unable to determine the integral function.

[Aaron Meurer]

That's correct. If integrate() returns an unevaluated Integral, it
means the algorithm couldn't compute an integral. The fu() function is
able to simplify this expression (it equals 2*sin(x)), so
integrate(fu(fx), x) works.

Aaron Meurer

> --
> 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 sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/6788d9f9-659d-48ab-bb68-3b3c8745bbe4%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Dario Beraldi]

Thanks guys! I didn't know about the fu() function.
Dario

[Francesco Bonazzi]

On Sunday, October 12, 2014 1:50:10 AM UTC+2, Aaron Meurer wrote:

That's correct. If integrate() returns an unevaluated Integral, it
means the algorithm couldn't compute an integral. The fu() function is
able to simplify this expression (it equals 2*sin(x)), so
integrate(fu(fx), x) works.

Why is fu( ) not attempted in the integrate( ) algorithm?

[Aaron Meurer]

I don't think integrate() tries any simplification. Ideally it
shouldn't have to.

Aaron Meurer

> --
> 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 sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sympy/6014ba22-a647-4e51-9905-730eadb5fd26%40googlegroups.com.

[Richard Fateman]

On Sunday, October 12, 2014 1:27:27 PM UTC-7, Aaron Meurer wrote:

I don't think integrate() tries any simplification. Ideally it
shouldn't have to.

Why not?  It seems to me quite the opposite.  That is, integration is
much easier if the input is first converted to some   canonical form
(or one of a few canonical forms).

RJF

[Aaron Meurer]

Because it's nicer when the output looks like the input. For
instance, sin and cos are easier to integrate if rewritten as tan
first, but it's annoying to write integrate(sin(x)) and get
-2/(tan(x/2)**2 + 1) instead of -cos(x).

For elementary functions, such as this one, the Risch algorithm should
handle them no matter what they look like. To be sure, internally it
might need to do all kinds of canoncalizing, but the difference is
that it can do very targeted simplifications and try to put things
back when it is done. It's hard to tell the generic simplify()
something as simple as "ignore anything that doesn't have x" (i.e.,
don't try simplifying complicated symbolic constants).

The other issue is that simplify() can sometimes be very slow, and it
would be a shame to run it if it weren't needed.

Also, note that the Risch algorithm for trig functions isn't actually
implemented in SymPy yet. I'm just pointing out that when it is
implemented, it will handle this better.

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/b04a7673-6ea0-4f3b-82ab-fef23babde38%40googlegroups.com.

[Richard Fateman]

On Wednesday, October 15, 2014 12:29:52 PM UTC-7, Aaron Meurer wrote:

Because it's nicer when the output looks like the input.

I agree

 

 For
instance, sin and cos are easier to integrate if rewritten as tan
first, but it's annoying to write integrate(sin(x)) and get
-2/(tan(x/2)**2 + 1) instead of -cos(x).

So you can take the answer and convert it to sin/cos. 

For elementary functions, such as this one, the Risch algorithm should
handle them no matter what they look like. To be sure, internally it
might need to do all kinds of canoncalizing, but the difference is
that it can do very targeted simplifications and try to put things
back when it is done.

The same kind of targeted simplification could be done on the 

the tan(x/2) expression.  If you can do it..

 

It's hard to tell the generic simplify()
something as simple as "ignore anything that doesn't have x" (i.e.,
don't try simplifying complicated symbolic constants).

It doesn't seem like a hard task to have a different driver program that

calls simplify only on subexpressions containing the integration variable.

 

The other issue is that simplify() can sometimes be very slow, and it
would be a shame to run it if it weren't needed.

Again, I agree with you,  but the alternative --- of making sure that your

algorithms work on unsimplified inputs --- seems hard too.   I think that

most system have a rather modest simplify program but with extra-strength

ones lurking in the background.  For example, Maxima's  solve program

uses the radcan simplifier if some flag is set.

Mathematica has a program FullSimplify  which takes a very long time

and so is generally NOT used... 

Also, note that the Risch algorithm for trig functions isn't actually
implemented in SymPy yet. I'm just pointing out that when it is
implemented, it will handle this better.

You were concerned with speed when you talked about the simplifier..

Since the trig functions can be trivially rewritten as complex exponentials,

I guess you have not implemented the exponential case of Risch;

this should be one of the more straightforward parts.

Good luck

RJF

[Aaron Meurer]

We do have the exponential case implemented, but that produces such
bad outputs for trig functions that it doesn't even do it
automatically (it is trivial for users to do it manually using
rewrite(exp) if they really want to do it).

Aaron Meurer

> https://groups.google.com/d/msgid/sympy/b0d0723d-14db-4bea-9c69-858bc44b0222%40googlegroups.com.