@Markiyan Hirnyk 

It is interesting that this long term bug in trigsubs has been fixed in Maple 17:

> trigsubs(sin(a+b)^2-sin(a-b)^2)[];
                               sin(2 a) sin(2 b)

But not, this other one:

> trigsubs(-sin(a)-sin(b));
Error, (in trigsubs) expecting a sum or difference of two functions but got
-sin(a)-sin(b)

@Markiyan Hirnyk 

It is interesting that this long term bug in trigsubs has been fixed in Maple 17:

> trigsubs(sin(a+b)^2-sin(a-b)^2)[];
                               sin(2 a) sin(2 b)

But not, this other one:

> trigsubs(-sin(a)-sin(b));
Error, (in trigsubs) expecting a sum or difference of two functions but got
-sin(a)-sin(b)

@Axel Vogt 

Your road may be easier for you, but it is more obscure for me. A question to start following it. That proyective line IP^1 is what is called P^1 elsewhere as here? (I wonder about the "I" prefix). So, you are talking about the complex projective line or the Riemann sphere? If so yes, the  Riemann sphere is always what I have in mind, even when not stating or using explicitly.

If I understand you correctly, your (partial?) conclusion coincides (or approaches) mine. Basically, the branch points of g(z)=1/sqrt(P), with P=4*z^2+4*z+3, are the roots of P and infinity. Certainly, it is somewhat arbitrary the selection of the branch cuts joining these points. But whatever the choice, the unit circle crosses somewhere these branch cuts.

@Axel Vogt 

Your road may be easier for you, but it is more obscure for me. A question to start following it. That proyective line IP^1 is what is called P^1 elsewhere as here? (I wonder about the "I" prefix). So, you are talking about the complex projective line or the Riemann sphere? If so yes, the  Riemann sphere is always what I have in mind, even when not stating or using explicitly.

If I understand you correctly, your (partial?) conclusion coincides (or approaches) mine. Basically, the branch points of g(z)=1/sqrt(P), with P=4*z^2+4*z+3, are the roots of P and infinity. Certainly, it is somewhat arbitrary the selection of the branch cuts joining these points. But whatever the choice, the unit circle crosses somewhere these branch cuts.

@Markiyan Hirnyk 

Choosing the branch cut between the roots of 4*z^2+4*z+3, is equivalent to e.g. choosing the branch cut of ln(z) on the positive real axis (instead of the negative one). This alternative choice for the branch cut of ln(z) does not change z=infinity as a branch point for ln(z). And as g(z)=1/sqrt(P)=exp(-1/2*ln(P)), with P=4*z^2+4*z+3, g(z) has a branch point at infinity all the same, I think.

@Markiyan Hirnyk 

Choosing the branch cut between the roots of 4*z^2+4*z+3, is equivalent to e.g. choosing the branch cut of ln(z) on the positive real axis (instead of the negative one). This alternative choice for the branch cut of ln(z) does not change z=infinity as a branch point for ln(z). And as g(z)=1/sqrt(P)=exp(-1/2*ln(P)), with P=4*z^2+4*z+3, g(z) has a branch point at infinity all the same, I think.

Actually it works only within a single execution block. A section might have multiple execution blocks.

Actually it works only within a single execution block. A section might have multiple execution blocks.

@Axel Vogt 

You have shown the output of MultiSeries:-series, but you have omited the output of series. Let us see both:

> series(g(1/z), z); # puzzling by csgn(1/z)
                                 2                  4                   5
1/2 csgn(1/z) z - 1/4 csgn(1/z) z  + 1/8 csgn(1/z) z  - 7/64 csgn(1/z) z  +
       6
    O(z )
> 
> MultiSeries:-series(g(1/z), z, 2);
                             1/2      1/2
                            4        4     2      3
                            ---- z - ---- z  + O(z )
                             4        8

What puzzles you, namely csgn(1/z) is the key issue, in my opinion. Look at the plot of the real and imaginary parts in a vincinty of the origin:

plots:-plotcompare(g(1/z),expression_plot,5);

Certainly, it does not look like 1/2*z, but rather like 1/2*csgn(1/z)*z. So, I think that this is a bug in MultiSeries:-series, and its result cannot be used to compute any residue at infinity. Moreover, as far as I know, residues are computed at poles, not at branch points, as infinity for g(z).

@Axel Vogt 

You have shown the output of MultiSeries:-series, but you have omited the output of series. Let us see both:

> series(g(1/z), z); # puzzling by csgn(1/z)
                                 2                  4                   5
1/2 csgn(1/z) z - 1/4 csgn(1/z) z  + 1/8 csgn(1/z) z  - 7/64 csgn(1/z) z  +
       6
    O(z )
> 
> MultiSeries:-series(g(1/z), z, 2);
                             1/2      1/2
                            4        4     2      3
                            ---- z - ---- z  + O(z )
                             4        8

What puzzles you, namely csgn(1/z) is the key issue, in my opinion. Look at the plot of the real and imaginary parts in a vincinty of the origin:

plots:-plotcompare(g(1/z),expression_plot,5);

Certainly, it does not look like 1/2*z, but rather like 1/2*csgn(1/z)*z. So, I think that this is a bug in MultiSeries:-series, and its result cannot be used to compute any residue at infinity. Moreover, as far as I know, residues are computed at poles, not at branch points, as infinity for g(z).

@Axel Vogt 

My understanding is that infinity, where both branch cuts join, is a branch point. Basicaly derived from the branch point at infinity of ln(z):

FunctionAdvisor(branch_points,ln(z));
          [ln(z), `in`(z, [0, infinity + infinity I])]

And 1/sqrt(P)=exp(-1/2*ln(P)), where P is the polynomial. 

@Axel Vogt 

My understanding is that infinity, where both branch cuts join, is a branch point. Basicaly derived from the branch point at infinity of ln(z):

FunctionAdvisor(branch_points,ln(z));
          [ln(z), `in`(z, [0, infinity + infinity I])]

And 1/sqrt(P)=exp(-1/2*ln(P)), where P is the polynomial. 

@Axel Vogt 

The branch points for g(z) are the roots of the quadratic:

> solve(4*z^2+4*z+3,{z});;
                                   1/2                       1/2
               {z = - 1/2 + 1/2 I 2   }, {z = - 1/2 - 1/2 I 2   }

That is, the tips of the branch cuts shown above by Markiyan. Outside them, g(z) is entire (no poles), I think. E.g.:

> series(g(z),z=0);
          1/2      1/2         1/2          1/2          1/2
         3      2 3        16 3     3   56 3     4   16 3     5      6
         ---- - ------ z + ------- z  - ------- z  + ------- z  + O(z )
          3       9          81           243          243

And a plot looks like that:

plots:-plotcompare(g(z),expression_plot,5);

Hence, the integral on the "deformed" unit circle, that goes around the branch cuts, should be 0 (I guess that this is what you mean by homotopy invariance).

@Axel Vogt 

The branch points for g(z) are the roots of the quadratic:

> solve(4*z^2+4*z+3,{z});;
                                   1/2                       1/2
               {z = - 1/2 + 1/2 I 2   }, {z = - 1/2 - 1/2 I 2   }

That is, the tips of the branch cuts shown above by Markiyan. Outside them, g(z) is entire (no poles), I think. E.g.:

> series(g(z),z=0);
          1/2      1/2         1/2          1/2          1/2
         3      2 3        16 3     3   56 3     4   16 3     5      6
         ---- - ------ z + ------- z  - ------- z  + ------- z  + O(z )
          3       9          81           243          243

And a plot looks like that:

plots:-plotcompare(g(z),expression_plot,5);

Hence, the integral on the "deformed" unit circle, that goes around the branch cuts, should be 0 (I guess that this is what you mean by homotopy invariance).

@Carl Love 

It makes no practical difference here stating the method ftoc. See the output of:

infolevel[IntegrationTools]:=8:
int(g(c(t))*D(c)(t), t=0..1);

You will get the time spent in each integration method. Almost all the time is spent in the method ftoc, almost 100 times the next one (elliptictrig).

And almost all the time spent in the method ftoc is spent on discontinuity checking. Compare:

> CodeTools:-Usage(int(g(c(t))*D(c)(t), t=0..1,method=ftoc,continuous=true)):
memory used=2.83MiB, alloc change=32.00MiB, cpu time=69.00ms, real time=67.00ms

> CodeTools:-Usage(int(g(c(t))*D(c)(t), t=0..1,method=ftoc,continuous=false)):
memory used=431.08MiB, alloc change=78.01MiB, cpu time=7.34s, real time=7.21s