This is a bug in the is command. It's surprising to me, because often is does well, yet for this example it produces a wrong result while several other commands get there.

Curiously, it seems to depend on the Pi, in particular.

Download is_weakness.mw

I usually call solve wrapped in square brackets. That makes the result a list of solutions. And then I can always use the indexing the same way, even if there is just one solution.

sol := [solve( ... )];

sol[1]; # first solution, whether there are more than one, or not

sol[i]; # ith solution

sol[1][j]; # jth element of first solution

sol[i][j];  # jth element of ith solution

One thing you can try is to force the alternate method=RC of RootFinding:-Isolate . Or you could try some other options to that command. Note that the problem of finding all roots of a system of polynomials with rational coefficients can be hard.

In Maple you can view the interpreted Library source using commands like showstat command. For example,

showstat(RootFinding::Isolate);
showstat(fgbrs::rs_isolate_sys);
showstat(fgbrs::rs_isolate_gb); 
showstat(fgbrs::rs_rur_sys);

The RS method of RootFinding:-Isolate makes calls to compiled libraries of the FGb and RS applications. It looks like it might be possible to utilize the 3rd party RS compiler libraries without a Maple interface layer, but I have no experience in doing so.

The RC method of RootFinding:-Isolate makes use of the RegularChains package (of which major portions are also in compiled libraries). See also the 3rd party homepage of the RegularChains project. I am not sure how easy it might be (if even possible) to utilize the compiled library portions without the Maple Library interface layer.

I don't think that you'd have joy trying to use these projects stand-alone outside Maple, unless you really enjoy programming riddles.

It might be that either of those 3rd party packages (including Maple full or partial interfaces) has a later version than what is shipped with your Maple version (even if current 2017.3). Even if true I don't know what compatibility issues might arise. It might not even be the case.

The global name can be accessed as :-x which distinguishes it from a local or parameter by the same name.

Below I throw single right quotes (a,k.a. uneval quotes) around it, because it's a good habit to protect such references against the case that the global name has been assigned a value (which is why mint complains). But for your example you can use :-x instead of ':-x' if you really want to.

test:=proc(function,{x::range:=0..1})
  plot(function,':-x'=x);
end proc:

test( sin(x) );

test( sin(x), x=2..4 );

IMO it's not great programming practice to restrict a procedure to work only for expressions that depend upon one particular name. Better would be to pass in the dependent name, or have the procedure figure it out, or pass in both name and range as an optional positional parameter.

Here are two possibilities (for Maple 2015 through 2017). One scheme incorporates the open brackets that Maple used in version 18 and earlier. The other scheme keeps the new, unfenced pretty-printing but applies a color.

Let me know if things like copy&paste work. The context-menu "Units formatting" may not allow changing the "system", but does seem OK with specific unit replacement (eg. N to replace m*kg/s^2).

Note that this only affects output. The behaviour of 2D Input (including use of the Units palette) appears the same.

Since Mapleprimes currently uses an old worksheet renderer (Maplenet?) the display below shows the older open brackets around the two schemes' outputs as well as for the default output of the initial statements executed before I redefine the print extension. (eg. for scheme 1 there are nested brackets.) I'm inlining the attachment here in this Answer anyway. In the Maple Standard GUI those extra open brackets don't appear in the output.

Download unit_print.mw

Please upload your worksheet using the green up-arrow in the Mapleprimes editor, instead of pasting in a screen-shot.

It's difficult to read your screen-shot image. But one thing that does stand out is that you're incorrectly using square brackets for grouping subexpressions. You need to use round brackets for that. (Square brackets are for creating lists.)

The assignments do succeed. They just don't print anything. If you want you can print something after the fact...

Download assignation_1.mw

Whether the 2D Input

   d := "hello"

echoes (in the output region) only the result or the whole assignment statement is behavior that varies according to a few things.

It varies according to whether interface(typesetting) is set to `extended` or `standard`.

It can also vary according to whether you are in an Execution Group (in a Worksheet say) or a Document-Block (in a Document).

I think it only makes sense to compare the same cases between versions.

Note the the default typesetting level changed from standard to extended, between Maple 2016 and 2017.

What major and minor versions are you using, precisely? Which typesetting level in each?

See the Grid package.

You could also look at the Threads package (but I suspect that it will not be suitable, if your computations involve code the is not thread-safe).

There is an undocumented export Hyperlink of the DocumentTools:-Layout subpackage.

You cannot get a hyperlink in regular printed output, but you can include it in embedded content.

hyperlink_embed.mw

With an explicit expression (formula) for the individual terms you can do symbolic summation using the sum command. For your example the summation can be computed to a closed-form expression formula, whose exact limit can then be taken, as Kitonum has shown.

But with a procedure that only computes the addition of a particular number of terms the limit command will not see any formula and so exact computation of the limit cannot be done. The procedure is then a black-box, as far as the limit command is concerned.

With such a procedure it is still possible to compute the limit to a non-exact floating-point value, by using a command that numerically computes the addition of various finite numbers of terms and then determines whether those results converge.

Download evalf_limit.mw

Short and simple is,

[seq(x>=0,x=A)];

In Maple 2017 one can also do it as follows (omitting use of a dummy name like x, but temporarily producing an additional sequence or list),

[seq(A)>=~0];

[seq(A)]>=~0;

You also asked why a particular attempt (to make similar results, but with lists of lists) failed, using the $ command.

The reason it failed is that when you call $ then Maple will evaluate the lhs argument using its usual evaluation rules for procedure calls. That means that arguments are evaluated up front, before the computations of the procedure begin. But you passed A[i,j] to the inner call to $, and that produces an error when i and j have not yet attained integer values. This kind of problem is jokingly referred to as premature evaluation. For this example you can repair that attempt by using two pairs on (unevaluation) single right-quotes to delay the evaluation of A[i,j] until i and j are numbers, because there are two nested function calls. It looks awkward. Or you can use seq instead of $.

A:=Matrix([[2,a],[b,3]]):

A[i,j];
Error, bad index into Matrix

[[(A[i,j]>=0)$i=1..2]$j=1..2];
Error, bad index into Matrix

[[(''A''[i,j]>=0)$i=1..2]$j=1..2];

              [[0 <= 2, 0 <= b], [0 <= a, 0 <= 3]]

[[seq('A'[i,j]>=0,i=1..2)]$j=1..2];

              [[0 <= 2, 0 <= b], [0 <= a, 0 <= 3]]

[seq([seq(A[i,j]>=0,i=1..2)],j=1..2)];

              [[0 <= 2, 0 <= b], [0 <= a, 0 <= 3]]

The reason that it works with seq is that the seq command has special evaluation rules.

If nops(g)>=n then g would have at least n operands, and then op(n,g) would exist.

But I suspect you are jumping the gun. Did you also intend to first check whether g were an expression of type `*` or type `+` , which means that g would be say a product or sum of terms.

Note that Maple uses several different sorts of structure and data structure. And several of those have operands, but with a different meaning for that concept. So asking about a specific operand of g only makes sense if you know what kind of animal g might be., and handle any different expected case appropriately.

Using _Maxim_'s good suggestion to instead compute the eigenvalues (which is faster than even using fsolve in an efficient way), and using the original Matrix which has since been added by the OP in a Comment, one can obtain the following:
 

In the actual worksheet the legend entries are not split with a newline. (That just happened when I uploaded here.) And if it happens in the sheet then one can un-hide the Table border and enlarge to fix.

Download eigenspect.mw

To assign to theta you need colon-equals, ie.,

  theta := 

not,

  theta =

The latter just produces an equality expression (and does not assign to theta), rather than making an assignment.

You didn't correctly copy that example code.