y:=x assuming 0<x: about(y);
x:
  nothing known about this object

assume (0<a): about(a);
Originally a, renamed a~:
  is assumed to be: RealRange(Open(0),infinity)

The tone of communication is a bit strange, by the way.

- looking at the plot it seems it is like periodic*linear, so may hope that "numapprox" will give you a reasonable numerical solution in one period without coding to much (guessing your parameters are 'typical') - that certainly can be compiled.

- may be it helps, if you post your integral as text and using conventions from Abramowitz & Stegun (Maple and MMA use different conventions, Maple uses A&S - I think)

Sum(k*exp(I*k*x)/(k^2+p^2+k), k = 1 .. infinity);
eval(%, [x=1/20, p=1/4]);
evalf[15](%): Im(%);

                           1.39226157632947

I want to consider it as a bug concerning the help "If the option parametric is specified for a definite parametric sum, then a result is returned that is valid at least for all possible integer values of the parameter(s) occurring in the summand or the summation bounds. In general ..."

Or at least: that description is not correct.

Fixing some p then plotting shows a discontinuity in x=0. Converting S to hypergeometrics Maple evaluates to 0 in x=0. That also allows [p=0, x=1] and gives ~ .543195529534400.

PS: I dislike insultings like "arguments over unbased words" a lot in this forum.

1. Perhaps you have a typo for your summation index (and please: post code, not pictures). Then it may be that Maple can even provide you with a symbolic solution (see answers below).

2. "Acceleration" is usually is used for numerical series, so all variables must have a numerical value (except your summation index, of course). Then Maple may give you the numerical result.

Those complex roots are conjugated pairs, here

RootOf(q, index=1) = conjugate(RootOf(q, index=3)); #allvalues(%);
evalf(%), is(%);

works and from that one finds it (sort out purely reals), expanding (x-RootOf(q, index=1))*(x -RootOf(q, index=3))

Looping is ugly and I have not tried higher degrees, so it is just a brute idea.

Yes ... and it still is thought as a comment.

I also think that the integral over F(s,b)/b * cos(b) is divergent:

One either can set b=0 in F and see that it can not cancel out the numerator in s=0

or

eval(F, beta=0):
MultiSeries:-series(%, s=0, 4) assuming 0 < s;

or

eval(F, beta=0):
MultiSeries:-multiseries(%, s=0, 2, 'exact_order') assuming 0 < s;

TT:=subs(int=Int, TT):
Change(TT, {x = (1/2)*a*(xi+1), y = (1/2)*b*(eta+1)}, [xi,eta]):
simplify(%): simplify(%, size); #convert(%, Diff);

PS: you also may wish to clean up your initialisation file - it is likely responsible for the error message after restart.

@dharr 

One may use the inert form as well, capital letters:
 

Download MP_221157.mw

@Preben Alsholm 

Digits *should* not be the actual problem - it is just setting x ---> x*I, and if a Real valued solver is used then this should not matter. My 'feeling' is that Re(..) or Im(..) can not treat it as a polynomial (there is no reason why the solver should assume x::real)

I get that error already with Digit=48 (and a smaller number), may be due to my machine / settings.

restart; N:=40: Digits:=15: F:=expand(mul(I*x-k,k=1..N)): f:=evalf(F): S:=[fsolve(f,complex)];

gives a really odd result, zeros should be x = -I*k

Reminds me of http://www.mapleprimes.com/questions/220963-Why-Maple-Could-Not-Solve-This-Expression

One may consider this as an "appendix" to already existing answers ...

I think you need higher precision, like Digits:= 256 or similar due to the "ill posed" situation, if you have no better idea or specific knowledge about the task.

There are ways to estimate the magnitude of the roots (= absolute value, which means "they are located in a circle, centered in 0, with that radius"), like https://en.wikipedia.org/wiki/Properties_of_polynomial_roots#Bounds_on_.28complex.29_polynomial_roots

For your task: 9.8 <= abs(root) <= 1.2*10^7

If you use convert(%, rational, exact) and then you may check the it:

# leading coefficient =1, x instead of beta (more easy to type, vv uses I*x)
aq/coeff(aq,beta,52): sort(%): subs(beta=x, %):
F:=convert(%, rational, exact);

with(RootFinding):
Digits:=256;
tmp:=[Analytic((F),x,-10-10*I..10+10*I)]; # two results
evalf[15](%); # to read it better

tmp[2]; eval((F), x=%);
Digits:=15;

This "confirms" the zero - but with an "high error" (almost half the digits)

Now use Digits:=15 and feed the root - you will find an error of ~ 10^146.

This also suggests:

It may be that your input based on 10 digit decimals is not a good idea, since result is not "stable" against small changes.

Thus it might be that you have to analyze the specific situation for your task instead of "brute force". If it is a practical task then usually over the decades such approaches have been developped.

@vv would you mind to sketch the example or point to a reference?

PS: yes, already dis- / proofing zero for one term only is beyond a CAS in general, so Laurent series are not a general recipe ...

23  bit   ?