Moreover, the calls to the deprecated command evalm are not needed here.  Eg,

restart;
with(LinearAlgebra):
for n from 5 to 8 do:
  A[n]:=Matrix(n, (i,j)->piecewise(i=j,4, j=i+1,3, j=i-1,5, 0));
  P[n]:=Determinant(1-t*A[n]);
end do:
seq(P[n], n=5..8);

@evanhowington It doesn't usually make much sense to help someone "increase" their RAM usage. There are some situations where RAM usage and timing performance can be involved in a trade-off. But those situations relate to specific programming techniques, and as yet you haven't shown us any use of such by yourself.

And I don't see how that applies to the isprime command in the case that the work is shunted off to a GMP function.

By default Maple is not restricted in accessing RAM that it needs, up to the point that the OS can supply it (if that's what you mean). There are settings to limit its RAM use, but that's the opposite of what you've asked.

Or are you asking about something related to your own code that you're writing?

I am having difficulty following your explanations and questions.

Please do not change the Subject line of this Question. If you want to ask a programming question about RAM usage then feel free to post a new Question, as it doesn't so far seem related to this original posted Question (about where computation takes place and how to see progress).

@evanhowington What do you mean when you write of a "new" prime?

@asukumari A misspelling that is similar to a keyword is not necessarily a keyword error. You could have been trying to make a statement with the perfectly fine name locals, but have omitted the operator or terminator. The faulty version is not unambiguously wrong.

If I fix the typo, changing locals to local for the code as 1D Notation in an Execution Group then when I hit the Enter key the cursor is placed on the line,

    end if

Here too there could be more than one interpretation of what was intended. But the syntax problem is at that line, and the line is indicated. You are missing a statement terminator there.  (dharr already told you that he had to fix some missing statement terminators as well.)

@evanhowington The command NumberTheory:-IsMersenne simply looks up a table of known values, which someone at Maplesoft updates now and then.

restart;

kernelopts(opaquemodules=false):

eval(NumberTheory:-known_mersenne_exponents);

    [2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, 127, 521, 607, 1279, 2203,
     2281, 3217, 4253, 4423, 9689, 9941, 11213, 19937, 21701, 23209, 44497,
     86243, 110503, 132049, 216091, 756839, 859433, 1257787, 1398269,
     2976221, 3021377, 6972593, 13466917, 20996011, 24036583, 25964951,
     30402457, 32582657, 37156667, 42643801, 43112609, 57885161, 74207281]

@evanhowington The following command returns true pretty much immediately in my Maple 2017.2 .

NumberTheory:-IsMersenne(74207281);
                   true

Of course this quick result involves a look-up, rather than a lengthy computation.

@Spinosaurus But of course it does work. You've mistaken my use of the word "stop" to mean that you should try and execute the word "stop" as a statement.

I was trying to convey that you can use any usual programming facility in Maple to control the flow of your program, using the conditional test f1 = "0" .  But we cannot read your mind about how you want the rest of the program to be, or in what context you wish to do this.

The ambiguity resides in your own phrase, "stop executing". What's supposed to stop executing? Some current do-loop? Some current procedure call? Or what?

When I write, "return/break/next/stop/end/etc as you wish" I mean that you should choose to control the flow according to whatever programming context your call to maplet is in. If it occurs within a procedure then you may wish to have it return. If it happens with a loop then you may wish to do next. And so on and so forth...

The return value after the Maplet closes is either a list containing a filename string, or (if Shutdown via Cancel) it is just the string "0". So your whole Question could be rephrased as, say: How can I stop execution of an algorithm when the value of a name like `f1` is the string "0"? That question is not about Maplets in any way.

When running the code below, you can select the Shutdown button each time, and see that it does not proceeed to the assignment to a and b.  I give you a variety of programming contexts in which the maple call could be made. There are even more such programming contexts possible.

Download shutdown_works.mw

@digerdiga In the context of a call to the type command identical(thing1,thing2,...) is used to denote some match to the particular expression thing1 or thing2, etc.

Some toy examples (which could also be done other ways),

restart;

expr := sin(x) + sin(3*q) + sin(t) + sin(w) + sin(q)
        + cos(x) + cos(3*q) + cos(t) + cos(w) + cos(q):

# Function calls of `sin` on arguments identical to w or 3*q 
indets( expr, specfunc(identical(w,3*q), sin) );

                       {sin(w), sin(3 q)}

# Function calls of `sin`or `cos` on arguments identical to w or 3*q 
indets( expr, specfunc(identical(w,3*q), {sin,cos}) );

               {cos(w), cos(3 q), sin(w), sin(3 q)}

# As the previous, but excluding the expression identical to cos(w)
indets( expr, And(specfunc(identical(w,3*q), {sin,cos}),
                  Non(identical(cos(w)))) );

                     {cos(3 q), sin(w), sin(3 q)}

Of course for those toy examples we could more easily just construct the resulting results directly. But the type mechanism allows us to do even more complicated structured type-matching.

Also, the close relationship between the commands indets and subsindets is very convenient. Once you've figured out the indets call which matches your intended subexpressions then you can simply turn the indets call into a subsindets call and supply its 3rd argument which denotes the action to apply to those subexpressions. Eg,

indets( expr, specfunc(identical(w,3*q,q), {sin,cos}) );

              {cos(q), cos(w), cos(3 q), sin(q), sin(w), sin(3 q)}

subsindets( expr, specfunc(identical(w,3*q,q), {sin,cos}), K );

      sin(x) + K(sin(3 q)) + sin(t) + K(sin(w)) + K(sin(q)) + cos(x) + K(cos(3 q))
      + cos(t) + K(cos(w)) + K(cos(q))

@John Fredsted 

It is not necessary to create a global type-extension procedure such as that `type/T`, as part of a two-step process for this.

More directly, and  incidentally without polluting the global namespace, an anonymous procedure (predicate) can be used withing the satisfies type. eg.

expr := -sin(alpha)*(sin(theta1)*cos(theta)-cos(theta1)*sin(theta))
        -cos(beta) *(sin(theta1)*sin(theta)+cos(theta1)*cos(theta)):

evalindets(expr, satisfies(x->not has(x,{alpha,beta})), combine);

          sin(alpha)*sin(-theta1+theta)-cos(beta)*cos(-theta1+theta)

Having said that, using either method this approach does not really work except in very special cases, because it disbars the subexpressions that we might want combined. For example, it doesn't accomplish any combining at all for the expression obtained by expand(expr) using the above.

It only happened to work for your example because the stuff to be combined was in the collected coefficients of the subterms containing alpha or beta.

@Markiyan Hirnyk 

Since I was discussing limitations of several commands (for the purpose of finding all real roots in a range, say) then it is indeed worthwhile to once again mention this important deficiency in DirectSearch:-SolveEquations. Other people reading this will not know to search Mapleprimes for mention of something of which they are not yet aware.

I am referring to this behavior, mentioned only as in a Note section of its Help page (and not its main Description section, though it's crucial detail): "The SolveEquations command can return not only exact solutions of the equation system but also any minimums of function F. If the residuals are too large then the solution is not exact solution, it is rather the solution that minimizes the residuals." That behavior contradicts the descriptions (made several times earlier in the command's Help page) that the command "solves" equations and finds "solutions" to equations such as "f[i](x)=0".

Behavior is not good or adequate merely be reason of being intentional and documented.

It's a poor design to allow local minima which do not actually solve the equations to be returned regardless of the magnitude of the residual. And the basic description is wrong because it incorrectly describes the behavior that is contradicted by the later Note.

The command ought to respect some (new) tolerance which allows rejection of results which have too high an absolute residual. And the caveat Note ought to be moved to the fore.

Narrowing down the specifics to a particular LPSolve `method` would lkkely help investigation.

So I suggest explicitly passing LPSolve's `method` option when reporting results here, so that we know whether that matters.

@Preben Alsholm I have seen a few such reports, since Maple 18/2015.

It's always been only 64bit Windows with the problem, afaik.

There may be more than one kind of issue, and/or more than one cause. I've seen both the crash and the incorrect result situations.

I know that these aspects changed, around then:

1) new interior point method (and linked to UMFPACK?)

2) switch from generic external CLAPACK + MKL BLAS to MKL LAPACK + MKL BLAS 

3) switch between MKL's so-called 32bit interface layer and 64bit interface layer for integer arguments

4) switch of linkage model (MKL has several)

There is even the possibility of vendor architecture dependency (think Intel vs AMD cpus). But that seems unlikely because the issues seem confined to MS-Windows.

One aspect that seems weird to me is that some people can reproduce it consistently while others never seem to see it.

So there are aspects which hint that it's not a short/long argument mismatch thing, or a memory violation, or a linkage thing because then I'd expect all participants to see it (albeit irregularly).

Murky waters. As I said, there may be separate causes/issues. 

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