You can use the view option to set the vertical range (or both horizontal and vertical ranges). You can use that with the plot and the implicitplot commands. For implicitplot there is also a convenient rangeasview option which forces the view to match the supplied ranges.

restart;
with(plots):

a,b:=7/10,0.2:

implicitplot(y=a*x+b, x=-10..10, y=-10..10,
             axis=[gridlines=[10,color=blue]],
             rangeasview);

implicitplot(y=a*x+b, x=-10..10, y=-10..10,
             axis=[gridlines=[10,color=blue]],
             view=[-10..10,-10..10]);

plot(a*x+b, x=-10..10, view=[-10..10,-10..10],
     axis=[gridlines=[10,color=blue]]);

plot(a*x+b, x=-10..10, view=[default,-10..10],
     axis=[gridlines=[10,color=blue]]);

plot(a*x+b, x=-10..10, view=-10..10,
     axis=[gridlines=[10,color=blue]]);

I suspect that the sky would not necessarily fall down if the Maple kernel developers allowed symbolic Matrix indexing to not throw an error.

Download matrix_ref.mw

First lets see that PolynomialFit can indeed produce a better result, if its svdtolerance option is set fine enough.

Download svdtol.mw

Next, let's examine why the rank determination under PolynomialFit may have numeric difficulties using defaults. And we can do the least-squares solving using LinearAlgebra and a suitable raised working precision (Digits).

And then, at end, we'll see that CurveFitting:-LeastSquares can also find a similar result if Digits is set higher.

Download svd_fit.mw

The behavior which you describe with the "yyyyy" characters is its being rendered in italics, because the following space indicates to the parser that the preceding yyyyy is a name.

You can disable that behavior of rendering input variable names in italics in the CLI by issuing the command,
    interface(ansiedit=false):

But note that doing so will disable some colorizing of input, which is on by default.

See the ?interface Help page.

With a differently simplified form of the chareq expression (using Maple 18.02). The form of U2 below is quite a bit more compact, although I did not stress test any of the forms for the degree of susceptibility to numeric roundoff error in any range of En.

I had just finished writing this when I saw that dharr had submitted a second answer, also with a suggestion about NextZero (although, used with care, Calculus1:-Roots can also find more). I suppose a third Answer doesn't hurt.

Download qm_maple_-_periodic_potentials_acc.mw

Two ways, using a symbolic option (instead of assumptions):

Download symbolic_ac.mw

It should probably emit an error if method=_MonteCarlo is forced and epsilon is supplied smaller than the method supports. And perhaps it should emit a Warning and bump up the tolerance if that method alone is supplied.

But I don't understand your initial statement, "...all the others seem to fail". Your example works even if no method or options are supplied.

Do you understand that forcing method=_CubaVegas may also fail at default options but succeed at others? It works for me using epsilon=1e-4. See the Help pages for additional details on suboptions, ie, ?evalf,int,cuba

Download evalf_Int_ac.mw

Download stacklimit.mw

L := [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]:

[seq(L[2*i-1]..L[2*i],i=1..nops(L)/2)];

        [1 .. 2, 3 .. 4, 5 .. 6, 7 .. 8, 9 .. 10]

I don't see how your question makes it clear whether you want the braces or their contents to be colored. So I have to guess. I guess it's the contents. (If it's the brackets -- or both -- then I don't see that you've sensibly described how to color it.)

It's not clear exactly how you want the colors "tweaked" with each iteration. But you might adjust this to taste:

Download color_recur.mw

[edit] Transitioning from color to color can be a subtle business. You might prefer the "Lab" colorspace rather than "RGB" since the former grades perceptually evenly (RGB runs evenly in terms of the monitor output, not perceptually). Two colors whose midpoint isn't some gray near the white point may also be nicer. Just let me know.

Also, the braces can be colored, but if that's desired then I'm not understanding the target details.

You can use the command evalf to compute that single floating-point arctrig call.

evalf[15](arccos(0.62))

             0.902053623592525

The command factor can be used to factor this polynomial.

p := x^5-11*x^4+27*x^3+67*x^2-320*x+300:

factor(p)

                       2        2
        (x + 3) (x - 2)  (x - 5) 

Are you trying to compute approximations of only the real roots, or also complex roots?

You still haven't shown your larger example where computation takes too long. is it a polynomial sysyem?

How much accuracy do you want?

The eliminate command can (fortuitously) be used to see that d[1] also has a special value. And c[0] and d[0] can be recognized by the trivial eq[7] and eq[8]. But RootFinding:-Isolate would also find the real solutions without that finesse.

There are various other possible apporaches (using calls to solve, eliminate, evalf, etc). But if you are only looking for the real roots of a polynomial system with exact coefficient then Isolate has the advantage of attaining a target accuracy without so much fuss over having to raise working precision to avoid roundoff error.

Download poly_system.mw

So, you have four different instances of the pair of tables Beams and Beams2?

Why not store them with one more (cheap) layer of indirection? That is to say, have four differently named parent tables (eg, BeamsTable[1], BeamsTable[2], ...) each of which contains their own distinct pair?

BeamsTable[1][Beams] is one, from a pair
BeamsTable[1][Beams2] is the other, from that pair

Or you could name the distinct parents BeamsTable1, BeamsTable2, etc. That could mean slightly less effort in storing them, with completely separate calls.

You don't even need to use different .mla files. You could utilize just one.

One of the points I tried to convey in my response to your previous (related) question is that you need to manage the global namespace of your Maple sessions. I likely was not clear enough about that. It should be done through deliberately assigned names (in Maple), and not attempted as a byproduct of external filenames/locations.

Saying it another way: don't store different things under identical names in .mla files if you want to retrieve them as distinct things. Trying to leverage the file system for that (provided that you don't need more than one distinct access per restart) could be accomplished, but it's really not a good way to go about it. And more general access (within restart) is going to present some near-impossible scenarios.

nb. In your earlier thread I did not mention storing in plaintext (input Maple notation), because I assumed that you would not want any solution which incurred the overhead of reparsing the language input code -- per session.

What precisely do you mean? You haven't given any example to illustrate. The LinearAlgebra:-Eigenvectors command already returns both vectors and values, so you must mean something else. I will guess.

Are you trying to say that you like the syntax where the number of computed and returned objects depends on the number of entries in the sequence on the left-hand side of the assignment statement? That is, where the particular computation (with the same right-hand side of the statement) varies according to whether the assignmnent is,
  (a,b) := ....
or
  a := ....
The former computes and returns two items (eg, both the eigen-vectors and values), while the latter computes just one (eg. only the eigen-values).

Personally, I find that syntax to be poor and disjointed. I am glad that no other commands have taken up this un-Maplelike syntax (as any further cloying attempt at Matlab emulation). I suppose it's a matter of personal preference.

For those interested, that functionality is implemented using the _nresults item in the context of procedure parameter-processing.

MTM is now a regular package of Maple (alone), rather than a toolbox. (Documentation of connectivity with Matlab is not great. But the MTM computational commands are available.)