@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

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.)