@tomleslie

Right, those are the values obtained by first evaluating the integrals with symbolic a and b and then substituting numeric values. That's what I get too. The expected results are:

Li(1/2)-Li(-1/2)+I*Pi;

1/8*(4-2*sqrt(-2+sqrt(13))+3*ln(2+sqrt(13)-2*sqrt(2+sqrt(13))));

I*(ln(37/5)/4+arctan(16/503));

I'm not sure why you convert the results to floating point and then try to guess the exact quantities you started with.

@Carl Love

Strictly speaking, it's already analytic, even if it's written in terms of abs/arg, the question is just how to rewrite it nicely:

ee := int(f(a+I*b, t), t = 0 .. infinity) assuming a > 0, b > 0;

simplify(convert(subs({a = Re(z), b = Im(z)}, arctan(Im(z)/Re(z)) = -I*(ln(z)-ln(abs(z))), ee), abs));
                    2       3          2                3
       24 I Pi ln(z)  - 3 Pi  z + 16 Pi  ln(z) - 8 ln(z) 
       --------------------------------------------------
                               2                         
                           24 z  + 24                    

(The integral converges uniformly in z when z is in any compact subset of the upper half-plane. That's enough for it to be an analytic function of z in the upper half-plane.)

I used argument=arctan(Im/Re), valid in the first quadrant. But since the function is analytic, the result is already valid for the whole upper half-plane.

@acer

...the less sense it all makes. If one clause of a conjunction is false, the conjunction should be false. But here false means true.

Also, RealRange isn't a type, but evalb(x::RealRange(1,2)) doesn't give an error like for evalb(x::real).

Yes, for the actual code I think I'll just use assum := {cond1, cond2, ...} and then e assuming op(assum).

@acer

Ohhh. I thought that the issue with (Im(a)>0 and a<>0) was due to the fact that some parts of the code were able to figure out the inference while others couldn't. But if Maple uses evalb, it actually just throws out an independent condition:

is(abs(x) > 0) assuming x <> 0;
                              true

is(abs(x) > 0) assuming x <> 0 and y > 0;
                             false

evalb will obliterate other assumptions as well, such as x::RealRange(1, 2).

(Also, it wouldn't be enough to say that a sequence of assumptions works like "and". Because... which "and"?)

Types do seem to work in assumptions: a::even, a::positive, a::posint all work, a::realcons works as well, it's just much more limited than a::real. Perhaps they all are "properties" as well as "types". There doesn't seem to be a list of valid properties anywhere, that would document things like real, complex, RealRange, which are not types.

@Carl Love

In 2017.2 that note instead says

• Note: In some cases, the execution may not abort at exactly the time limit imposed, but will abort as soon as it can do so safely.  This can happen when execution is in critical sections of certain built-in routines.

timelimit(30, evalf(int(GAMMA(s), s = 1-I*infinity .. 1+I*infinity))); # ~40 seconds
Error, (in evalf/lnGAMMA/asympt) time expired

@Preben Alsholm

We know how int interprets those infinities:

int(f(s), s = 1-I*infinity .. 1+I*infinity);
          int(I f(I s + 1), s = -infinity .. infinity)

int(f(s), s = I .. infinity+I);
                int(f(s + I), s = 0 .. infinity)

So yes, it's always a vertical or a horizontal line. It's in agreement with what the documentation for infinity says: 1+I*infinity (or I+infinity) remember the direction and also remember that they have a constant real (or imaginary) part. This is exactly what's needed when describing the contours for MeijerG integration.

One cannot define integration contours from (-1-I)*infinity to (1+I)*infinity in this way, because those are the same infinity:

(-1-I)*infinity;
                     -infinity - infinity I
(1+I)*infinity;
                     infinity + infinity I
is(%% = %);
                              true

But:

Re((-1-I)*infinity);
                           -infinity
Re((1+I)*infinity);
                            infinity

So they're equal but their real parts are not. I think it's wrong that those two are printed differently and that their real parts are different. The documentation clearly says that they're the same point; argument is undefined and Re/Im should be undefined too.

@Carl Love

Not sure if it makes the issue less or more annoying, but the kernel seems to handle timelimit interrupts much better. A global timelimit to be applied to every top-level command would be a poor man's solution. Sometimes timelimit(30, e) is going to take closer to 50 seconds than 30, but still would be better than having the worksheet lock up.

@Carl Love

It seems to be one of those cases where Maple uses method=discrete by default. With method=custom, I get reasonable values for Mean and StandardDeviation.

Probably belongs in this thread too:

evalc(ln(z/abs(z))) assuming z::complex;
                       /        z         \
                     ln|------------------|
                       \|evalc/unsplit(z)|/

The use of assumptions to override the default behavior of evalc is, of course, documented.

Also, I said that convert(...,abs) sometimes works for a reason. For cases like abs(sin(z))-sqrt(cosh(Im(z))^2-cos(Re(z))^2), it's not as immediate. Besides, when working through this example with x and y, at some point we need the sign of cosh(y)^2-cos(x)^2. But without assumptions on x and y, it's unknown. We have to assume x::real, y::real. If evalc and/or simplify were more flexible when dealing with complex arguments, there would be no need for those assumptions, because Re(z)::real and Im(z)::real are automatic.

@Markiyan Hirnyk

Well, don't underestimate Maple, it's smart enough not to rely on evalf in cases like this one. Without abs, signum(0, tan(Pi/5)-sqrt(5-2*sqrt(5)), 0) stays unevaluated. evalr works with intervals.

@ecterrab

I'd say FunctionAdvisor returns only a subset of what asympt returns, because asympt works for hypergeom([1, 1], [2, 2], -z) but FunctionAdvisor(asymptotic_expansion,...) gives "Error, (in FunctionAdvisor) invalid input".

P.S. Except of course there is a catch, and for signum this happens:

diff(signum(f(z)), z);
                        signum(1, f(z))

In all other cases Maple includes D(f)(z) in the answer. I think this is just an oversight, because I don't see how the result without D(f)(z) can be useful.

So this extra definition is needed:

`diff/signum` := (fz, z) -> signum(1, fz)*diff(fz, z);

Then examples like this work:

ddiff(f(conjugate(g(z))*signum(g(z))^2), z, w);
                                / d      \
                     D(f)(g(z)) |--- g(z)|
                                \ dz     /

@ecterrab 

I see, so the automatic simplification is the issue, and it's the same in the second example:

MeijerG([[], [1]], [[0, 2], []], z);
               -MeijerG([[1], []], [[2], [0]], z)

Everything after that step seems to be fine, but the input and output are already different. Except this time the transformation is invalid everywhere, not just on the branch cut.

@Carl Love 

Thanks. 'parametric' seems to be better for this type of problems. It has some hiccups too, particularly for degenerate cases:

solve({x^4+a*x+a^4 = 0, x^2+a^2 > 1}, x, parametric = full); # no solutions
Error, (in SolveTools:-SemiAlgebraic) piecewise takes at least 2 parameters

solve({x^4+a*x+a^4 = 0, x^2+a^2 < 1}, x, parametric = full); # solutions exist
Error, (in rootbound) 1st argument must be a polynomial with numeric coefficients

Also I cannot directly convert this kind of inequality into 'parametric':

solve(RootOf(_Z^3-_Z+a, index = real[1]) > 0, a); # wrong
                  RealRange(Open(0), infinity)

@Ramakrishnan 

Be careful when reevaluating evalf in the same session, it caches the results and just gives you the same value truncated to lower precision.