@kuwait1 You can do what I said by running the second attachment I added before, the one named ANALYTIC_1_M13.00.mw . That works, in Maple 13.00. And one of the included ways runs reasonably quickly.

@Markiyan Hirnyk He is using Maple 13.00, and in that version RootFinding:-Analytic does not do so well as can be easily achieved using Calculus1:-Roots . 

Also, if you had bother to see my previous attachments you'd see that for this example the performance using Calculus1:-Roots can be much improved by first combining and (optionally) applying fnormal.

In my Maple 13.00, if I call Analytic(ee,phi=0-I..10+I) on ee the original expression it produces the 12 roots between 0 and 10 (as well as 0.+0.*I) in 10.8 seconds. But calling Calculus1:-Roots on fnormal(combine(ee)) produces those same 12 real roots in 1.4 seconds, while calling Analytic on fnormal(combine(ee)) produces and error message about "too many levels of recursion" after 72 seconds.

ANALYTIC_2_M13.00.mw

@Markiyan Hirnyk I had already considered that aspect when I made my Answer.

I still believe that the `timelimit` command best addresses the actual Question asked, which was about simple stopping of a subcomputation taking too long. There's no other action that would interrupt during a kernel built-in rather than an interpreted (e.g. Library) call, so it doesn't bear on the choice of mechanism.

I would hope the OP would read the Help page of the command I suggested.

@gaurav_rs I do see both the superscript "2" and the rest bolded, but the weighting effect on the superscript is less (because it's at a smaller size).

What seems to look better is to explicitly bold only the superscript (exponent) while leaving the rest unbolded.

See below for a screenshot, using labelfont=[Time,N] and only the superscript bolded.

The details are in this revised attachment. cust_label_2.mw

Also, the relative size of the superscript can be adjusted. For example you could experiment with ceil(0.67*N) instead of ceil(0.5*N), etc.

I produced the above screenshot in Linux. On MS-Windows or OSX the font might render slightly differently. My revised attachment shows both fonts "Times" and "Helvetica", and on MS-Windows you could also try, say, "Tacoma".

@9009134 I only changed it from fprintf to printf to show that my other edits/corrections made it work.

Just change that printf back to a suitable fprintf and it'll write to a file instead.

Your problem was mostly that F53 was set up wrongly.

I don't see why that's so hard to understand.

@9009134 Did you notice that I changed the fprintf to printf, to illustrate that it produces the numeric results?

@sand15 FYI, you might also find this old thread of interest.

There, maple is the installed Linux shell script that launches Maple Command Line Interface (CLI) in a shell (while you might be using cmaple.exe).

From your wording it is not clear whether you: 1) want to plot a surface (expression in x,y,z) whose domain and range are constrained by those inequalities, or 2) just want to plot the boundaries of the constrained region.

If it is the first case then is the expression explicit like z=f(x,y) so that you could use the plot3d command, or is it only implicit like f(x,y,z)=0 so that the implicitplot3d command is needed?

If there is an expression in x,y,z to be plotted over the constrained region then show it to us.

@quo Yep. It's the same command, with all the same arguments except the one with `typesetdot`.

Typesetting:-Settings(usedot=true, dot=t);

IIRC those might even be default settings in Maple 2016. (I forget, offhand.) You'll have to ensure

interface(typesetting=extended):

since it might not be your default in 2016 (though it is in 2017). You probably already know that this aspect can be set as a GUI preference and stored "Globally" across sessions, via the menubar's Tools->Options.

In either Maple version you can read more details on the Help page for Typesetting:-Settings .

@quo The command Typesetting:-Settings only accepts the keyword `typesetdot` as of version Maple 2017.0.

I wrote the code that way because your Question here was marked as "Maple 2017".

Is it possible that you pasted that code into Maple 2016 or earlier, by mistake?

I am not sure why those other Inputs are not working (or being saved in the .mw file).

But I notice that the test_document.mw was last saved with Maple 2016.1. Have you considered getting the later point-release 2016.2? See here. (I don't know that this will remedy the situation, but it might be worth doing regardless.)

@colinbannister Note that OMP_NUM_THREADS only controls the numeric Linear Algebra done in hardware working precosion via the MKL.

If you also want to restrict/contain multi-threading done via either Maple's internal garbage-collector or its Threads package then you also need to set kernelopts(numcpus) as per comments above.

Neither setting (alone, by itself) controls all the kinds of multicore use that can occur.

@Adri van der Meer 

I notice that attached worksheet in the Original Poster's Question was made with Maple 2015.2.

And indeed your workaround to use one pair of (single right-quotes) unevaluation quotes works in version 2015.2 (and earlier, eg. version 18.02).

I also notice that in at least the 64bit Linux Maple versions 2016.0, 2016.1, 2016.2, and 2017.0 that approach of delaying any premature evaluation with just one pair of unevaluation quotes of the function call p(u,v) does not work. But it does seem to work on in Maple 2016 and Maple 2017 with two (nested) pairs of unevaluation quotes.

I am going to submit a bug report against this regression in behavior.

@Kitonum That's simple and very clear.

(We've switched earlier roles for this particular example, mine being geometrically inspired.)

You've motivated me to add a plot. (Perhaps it'd be more clear to show or mention that the red line goes through the origin...)

@mehdibaghaee 

Your first statement assigns a Matrix to the (typeset) 2D Input name

    `#mover(mi("Δ",fontstyle = "normal"),mo("&uminus0;"))`

Your second statement, which assigns to K, references another name,

    '`#mover(mi("Δ"),mo("&uminus0;"))`'

They both get pretty-printed the same, but they are distinct names.

You could delete the instances of the problematic name in the second statement, and then copy and paste the name from the first statement instead. That worked for me, using your document in 64bit Maple 2017.0 for Windows.

I discovered the problem by copying both names and pasting them into an execution group that was toggled to 1D Maple Notation.