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

@Carl Love He wrote that he'd initialized parameters (presumably to numeric values). But that doesn't necessarily mean that Matrix K is yet all of type numeric. See example below.

I'd say that the OP's particular call to convert is somewhat obscure and cryptic, though. In modern Maple there are lots of simpler ways to hit all of Matrix K with evalhf and make the result have datatype=float[8].

K:=Matrix([[sin(5)]]):

M:= Matrix(K, datatype= float[8]);
Error, (in Matrix) unable to store 'sin(5)' when datatype=float[8]

evalhf(K);
                            [-0.958924274663138]
rtable_options(%,datatype);
                                  float[8]

Matrix(evalhf(K), datatype= float[8]);
                            [-0.958924274663138]

Matrix(evalhf~(K), datatype= float[8]);
                            [-0.958924274663138]

# Even this is simpler, working as far back as Maple 6?
Matrix(map(evalhf,K), datatype= float[8]);
                            [-0.958924274663138]

Matrix(`~`[convert](K, float[8]), datatype = float[8]);
                            [-0.958924274663138]

@toandhsp Welcome to the party. We are all at the mercy of solve and other Maple commands.

Perhaps there are other tacks, for this new example:

restart;

z := a+I*b:
C:=evalc(3*abs(z-4-3*I)+4*abs(z-8-6*I) = 20):

eq:=a=4/3*b: # where the fun is

simplify(eval(C,eq)) assuming real;

         1                                                          
         - (20 b - 120) signum(b - 6) + 5 signum(b - 3) (b - 3) = 20
         3    
                                                      
b=solve(eval(C,a=4/3*b)) assuming b>=3, b>=6:
eval(abs(a+b*I),[%,eval(eq,%)]), eval(eq,%), %;

                             75      60      45
                             --, a = --, b = --
                             7       7       7 

b=solve(eval(C,a=4/3*b)) assuming b>=3, b<=6:
eval(abs(a+b*I),[%,eval(eq,%)]), eval(eq,%), %;

                               5, a = 4, b = 3

@smiths I added my Comment above onto Kitonum's Answer, because (obviously, I had imagined) I was utilizing the same observation about "fixed points  A(-3, 2)  and  B(3, 8)".

If I had possessed a straightforward way to obtain the simple real-real restrictions on the a (or the b) of z=a+b*I then I would have submitted as an Answer instead. 

I was simply pointing out that, having introduced the a and b (and having made the observation about their ranges), it was not necessary to also work out and introduce a parametrization by t. And I also wanted to mention that there were at least (related) two ways of doing that.

I had thought that all the sensible people engaged in the discussion were already aware that the weakness (of solve, mostly) in generating the range restrictions on a and b was the outstanding issue. I didn't see much point it stating what others had already mentioned.

If I think of some reasonable, automated way, I'll mention it.