@dbain1 This runs OK in my Maple 16 for 64bit Linux.

Download int_pthroot_abs_M1601.mw

That's just using abs applied to the original integrand (as Carl suggested might be intended).

(Again, the presence of the literal name `expr` in your result's unevaluated inert integral makes me suspect that you didn't actually assign the integrand to `expr` when you first tried the last part of my Answer's worksheet. Please check.)

@Preben Alsholm I suspect that `evalf/int/control` is trying `evalf/int/singleft` (which converts to rational,exact and produces an exponent like 333333333/10000000000 which causes a symbolic blowup). This is unfortunate since method=_d01ajc can handle both Re and I*Im of the original integrand, quickly.

A common general way to avoid such issues is to supply the integral and range in operator form.

Another way, which happens work here but may not in general, is to use IntegrationTools:-Expand on (Re+Im*I) applied to the integrand.

But the questions arises: is `evalf/int/control` making the most effective choices?

@dbain1 Did you first run the code that assigned the integrand?

I can try with Maple 16 this evening, and Maple 15 tomorrow.

But try to execute the whole worksheet, every line in order. (You could also use the !!! button on the menu bar.)

Do you expect us to re-enter all the inputs manually? What commands came before this? How can we tell whether you're using atomic subscripting or indexed subscripting?

Upload your Document, using the green up-arrow in the Mapleprimes editor.

[Deleted: some incorrect comment about using ArrayInterpolation to obtain an interpolating procedure, in the hopes of using colorscheme with say plots:-contourplot. It doesn't look like contourplot supports colorscheme at present.]

I've updated my Answer to include a finesse to obtain a multicolored listcontplot (based on the given list fo colors) without monochrome contour curves. Instead, the contours are shaded according to an adjacent filled region's color.

Here are the two earlier versions (which may be flawed). I include then for anyone who likes to experiment and review.
Maple_s_test_1.mw
Maple_s_test_2.mw

@vv Another way to avoid the very small or zero-valued imaginary artefacts is to use the shape=symmetric option in a Matrix call around evalf(T).

Eg,

Eigenvectors(Matrix(evalf(T),shape=symmetric));

That will cause a different LAPACK function to be utilized by LinearAlgebra:-Eigenvectors.

Have you seen John's old Secret Santa Graph Theory post?

Would it be easier using plots:-surfdata?

@Aaeru Michi Please feel free to ask specific syntax questions in separate new threads, while trying to contain a broader theme to one thread.

If I was overzealous in my restrictive comment before, I apologize.

I applaud your goal of solving as much of the problem yourself as you can, after resolving usage issues.

@Aaeru Michi There's no need to start another thread for that question. Please don't.

@Ronan Mixed float/symbolic expressions are quite often problematic in general, not just here. I find it more curious that the problem occurs with exact values like Pi, sqrt(2), RootOf(_Z^2-2,_Z), etc, while succeeding for an unassigned name like foo.

I'm surprised that bare simplify finds that rhs-lhs is zero, while is falters on testing that rhs-lhs equals zero. In my experience zero-testing by is beats simplify (to obtain zero) more often.

And in these problematic cases is returns false, not FAIL.

I will submit a bug report.

What kind of coefficients do the polynomials have? Real exact rationals? Real floats? Exact radicals like sqrt(2)?

If all the coefficients are real and rational (or float) then you could use RootFinding:-Isolate. If they are real exact radical (or even just of type realcons) then you could apply evalf (and possibly fnormal) to get them all as real floats, and then use RootFinding:-Isolate.

Why not show them to us, in an uploaded worksheet?

Are you saying that your difficulty is with the white border around the 3-D plot window, because your figure is not square (e.g. tall and thin)?

@mapleatha In general there is no mechanism to instruct the solve command to return only purely real solutions.

In some special cases there are ways to get what you ask.

One way is to sieve out the non-real solutions, after the fact. This is only as good as the mechanism chosen for determining whether an expression is purely real. Quite often the is command can succeed (sometimes with assumptions on any additional parameters -- ie. non-solving-variables). Note that since is can return FAIL you have to decide whether to allow such a FAIL to produce false positives or false negatives.

This approach overlooks any means (if such even exists) to obtain only purely real solutions more quickly than all complex solutions are obtained.

restart;
p:=x^3-x-1:
sols:=[solve(p,x)]:
evalf(sols);
    [1.324717958, -0.6623589786 + 0.5622795125 I, -0.6623589786 - 0.5622795125 I]

rsols:=remove(is,sols,Non(real)):
evalf(rsols);
                                 [1.324717958]

In the case of a system of polynomials (with real, rational coefficients) you can try the real option to the solve command. Eg, compare,

forget(SolveTools); solve(x^3-x-1, x, allsolutions);

forget(SolveTools); solve(x^3-x-1, x, real, allsolutions);

If you have a system of polynomials with rational coefficients then you could also consider going straight to the SolveTools:-PolynomialSystem command, utilizing its domain=real option. Note the if you have a system of polynomials with real floating-point coefficients then you might choose to convert to rational so that you can try this approach.

In some cases supplying additional inequality bounds to the set of equations can help solve obtain only purely real solutions. This doesn't always work. Sometimes it interferes with solve's ability to produce all solutions.

There is also a package RealDomain, which exports its own RealDomain:-solve commmand which attempts to work only over the reals. There are many examples which defeat this, however, producing either some non-real results or missing some purely real results.

@Christopher2222 That will incorrectly remove too much. Consider the roots of a cubic, in the case that all are purely real but when expressed in radical form containg the imaginary unit.

For the purpose of this sieving I'll leave aside the fact in this case a trig representation, without the imaginary unit, might be attained using evalc. The key point is that the mere presence of the imaginary unit (in a particular represetation) does not mean that the expression is non-real.

restart;
p:=x^3+6*x^2-10:
sols:=[solve(p,x)];
remove(has,sols,I);  # oops, removes them all

evalc(sols);
evalf(evalc(sols));

remove(u->is(u::Non(real)),sols);