Have you considered installing the Maple 2016.2 point-release?

I am curious about just why it's going wrong. Would it be possible for you to reply with an attachment that ran the following code as separate execution groups in a Worksheet using 1D input?

kernelopts(version);

restart;
Optimization:-LPSolve(3*x__1+14*x__2+18*x__3+6*x__4+2*x__5,
       {3*x__1+5*x__2+6*x__3+2*x__4+x__5 <= 10},
        x__1 = 0 .. 1, x__2 = 0 .. 1, x__3 = 0 .. 1,
        x__4 = 0 .. 1, x__5 = 0 .. 1, maximize = true,
        method=activeset);

restart;
Optimization:-LPSolve(3*x__1+14*x__2+18*x__3+6*x__4+2*x__5,
       {3*x__1+5*x__2+6*x__3+2*x__4+x__5 <= 10},
        x__1 = 0 .. 1, x__2 = 0 .. 1, x__3 = 0 .. 1,
        x__4 = 0 .. 1, x__5 = 0 .. 1, maximize = true,
        method=interiorpoint);

restart;
Optimization:-LPSolve(3*x__1+14*x__2+18*x__3+6*x__4+2*x__5,
       {3*x__1+5*x__2+6*x__3+2*x__4+x__5 <= 10,
        x__1 >= 0, x__1 <= 1, x__2 >= 0, x__2 <= 1,
        x__3 >= 0, x__3 <= 1, x__4 >= 0, x__4 <= 1,
        x__5 >= 0, x__5 <= 1},
        maximize = true, method=activeset);

restart;
Optimization:-LPSolve(3*x__1+14*x__2+18*x__3+6*x__4+2*x__5,
       {3*x__1+5*x__2+6*x__3+2*x__4+x__5 <= 10,
        x__1 >= 0, x__1 <= 1, x__2 >= 0, x__2 <= 1,
        x__3 >= 0, x__3 <= 1, x__4 >= 0, x__4 <= 1,
        x__5 >= 0, x__5 <= 1},
        maximize = true, method=interiorpoint);

@tsunamiBTP 

The sum command attempts symbolic summation, and the add command adds up a finite number of things. You're trying to do the latter, and so add is the suitable command for your task. Do you really want your addition of many sin and cos calls to be turned into LerchPhi or whatever other special function calls that sum command might come up with?! There's at least one thread from the past week (same coursework?) where someone asked how to stop that from happening.

I very deliberately changed your example to use add instead of sum because it seemed the better tool for this job. I think that changing it back may be a mistake, and I would not be surprised if it led to additional, unnecessary difficulties. Such difficulties might be surmountable, perhaps by careful and expert attention. But if you don't understand why the symbolic summation result from sum is different in representation then you're probably going to find any such issues even more difficult to deal with yourself.

It's a Big Problem that the nicely formatted summation symbol (capital Greek letter Sigma), usable for 2D Input, is parsed as symbolic summation command sum. People grab it from the expression palette, or from command-completion. It looks very nice. It's very often the Wrong Thing for the Job. It was a big design mistake to put sum in the Expression Palette, IMO.

As for Calculus1:-Roots versus RootFinding:-NextZero, well, the former attempts to find all real roots in a range, repeatedly searching subintervals (between found roots using fsolve) until it can find no more. That can be expensive, especially when you pass Roots a range containing many roots. In sharp contrast, NextZero is only trying to find one single root (the next one higher than the supplied starting point), so of course its task is very often much less expensive.

Your given task here is to find the smallest root. If you know a lower point for the range then NextZero may well be good for you. I've found that NextZero is nice and fast and useful, right up until I give it a problem where it runs amok, computing apparently without ending. And I've found that it can miss roots more often. Perhaps your examples won't be problematic for it.

RootFinding:-Analytic can also be useful, until you have an example where there are also complex (nonreal) roots around. Then you can have to start sieving out the nonreal roots it returns, since making supplied the rectangular strip in the complex plane (over which it searches) be very narrow (small imaginary range) can make it miss roots. It seems that your current examples are not problematic for it, in this respect.

The DirectSearch:-SolveEquations command has its own problems. I think that it's silly that it doesn't properly respect its own forward-error tolerance option as a gatekeeper, and can return "solutions" which are local minima but not actually roots. I've seen people get tripped up by that, thinking that all its returned values are actually roots.

@tsunamiBTP 

fsolve_working.mw

The only way I know to programmatically construct and export an image such as a jpeg file containing expressions (numbers, text, formulas) is through use of textplot and plotsetup. But that'd entail figuring out all the formatting placement.

I'm not really sure else you might mean by "save this table". You could programmatically save each constructed GUI Table to its own .mw file. But are you wanting to export it to a saved file that can be imported as an image into some 3rd party application?

@vv I submitted a bug report this afternoon. I included the case of proc+constant, which I'd also noticed.

It's not because of typesetting=extended per se, but due to changes in `print/rtable`. Those changes may have been due to a few things, one of which is typesetting=extended. Another might be a different mechanism for parsing and evaluating 2D Input. (ie. the "print redirected thing seems to have gone, Document Blocks possibly now being 1 rather than 2 Execution Groups for separated input and output. And there have been cases -- reported here -- where 2D infix arithmetic calls get parsed to prefix form.)

It looks like there is fiddling going on in the point releases, as corner cases come under scrutiny. (eg, changes/fixes have been made for the Matrix palette.)

You example regressed from 2017.0 to 2017.1, it seems.

Did the regression begin with Maple 2017.1 ?

One way in which you've gone wrong is to include only an image of your code, but not the code itself. Either use the Mapleprimes editor's green up-arrow to attach your worksheet/document, or inline it as plaintext in 1D Maple Notation.

@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?