You could try DocumentTools:-Tabulate. The caveat is that command only allows for one such plot (or collection/Table of plots) printed immediately after each paragraph or execution group.

P1:=plot(sin(x),x=-Pi..Pi,size=[300,300]):
DocumentTools:-Tabulate([P1],alignment=left,exterior=none,
                        width=300,widthmode=pixels):

P2:=plot(sin(x),x=-Pi..Pi,size=[500,500]):
DocumentTools:-Tabulate([P2],alignment=left,exterior=none,
                        width=500,widthmode=pixels):

You can also do the above all manually, by inserting GUI Tables, toggling off their borders, making them left aligned, and using DocumentTools:-SetProperty to put plots into them programatically.

You can also force the output of a regular printing of a plot to be left-aligned using the main menubar. But as far as I know that quality is not persistent and is undone by re-execution. The same goes for plots:-display(Array([....]) where you weight the right portion with an empty plot and then toggle all the qualities of the inserted Table (which also don't persist upon re-execution).

By default the caret is too narrow, and is rendered to the left (perhaps not only because of the italic slant).

Two other ways to accomodate this are:

1) Augment the base symbol with an invisible space, so that the caret gets stretched and shifted right. This pushes the subscript slightly to the right, but the overall effect is still better than the original caret misplacement, IMO.

2) Use double-underscore rather than square-bracket indexing for the subscripting. This also shifts and strectches the caret. But (see below) the effect may be too much when the subscript is itself wide.

nb. In My Maple 2017.1 for Linux the carets looks a little narrower and sharper than they do as rendered inline below (by this site). But the placement and width effects are essential similiar.

Download overcaret.mw

Add the option phi = 0 .. infinity to your fsolve call, to avoid negative values for this example.

You can also use Student:-Calculus1:-Roots to get multiple roots within a finite range. Results may vary according to your Maple version, though. The first attachment below was run in Maple 2017.0, and you are using what, Maple 13.00 still?

ANALYTIC_1.mw

Here's an attachment that was run in Maple 13.00.

ANALYTIC_1_M13.00.mw

nb. Your original worksheet returned calls to Analytic, unevaluated, because you didn't first load the RootFinding package. You also failed to supply it with a (thin, complex) range for phi. [edited] See below for more, including another attachment by me.

Q2: For this example, you can obtain the desired simplification with just,

  simplify(ap2, size)

or,

  numer(ap2)/denom(ap2);

or,

  frontend(simplify, [ap2]);

Q3: note the t1(T) in the lhs of ap3 (as opposed to just your original t1 ).

ap3 := Diff(t1(T), T) = (m-T)/(m-t1(T));

ap4 := Diff(lhs(ap3), T) = subs(value(ap3), diff(rhs(ap3), T));

Q5: I don't understand why you thing that the originally supplied ap6 and ap7 are always equal.

Try the command `timelimit` which can wrap around another procedure call.

The `timelimit` command is intended for exactly the kind of situation you describe.

You can use the try...catch mechanism to control this flow.

When `timelimit` times out it emits an error, and your code can catch that, and proceed.

The command LinearAlgebra:-GenerateMatrix should be able to do that.

It's awkward to do, and not general, but... you can alter the Typesetting so that the exponent is smaller.

Making this more precise, say to affect only powers within sqrts, would be more involved.

Using labelfont=[...,bold,N] might make the two sizes appear more similar in weight.

cust_label.mw

Did you intend something more like,

F53 := eval(u(y), sol)

?

Also, assigning to `u` just makes it more difficult to re-use `sol`.

BVP_1.mw

I find the whole approach to be unnecessarily cryptic.

Why not use the -c option of cmaple, to assign the filename string (and read MyCode too if you want).

Then you just need Eclipse to form the full call to cmaple.

To get the dot notation for the derivatives you can issue this command at the top of the Document.

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

If you didn't need the derivatives to be pretty-printed in dot notation then you could simply set the typesetting level to standard. Getting the formatting effect you describe, without setting typesetting to standard, requires fooling the system into not recognizing that common 1/2 factor as being a rational number. There are a few ways to do that, some fancier than others. See this attachment formatting.mw .

As far as grouping with respect to particular variable names goes, see the collect command.

These should also produce a plot as shown in Adri's answer:

restart;
S:=proc(u,v) 10*u^2+20*u*v+15; end proc:
p:=proc(u,v) if u<v then S(u,v); else S(u,v)+10; end if; end proc:
h:=proc(u) 2*u; end proc:
plot3d([(u,v)->40*u,(u,v)->80*v,p], 0..1, 0..h);


restart;
ee:=10*u^2+20*u*v+15:
plot3d([40*u,80*v,piecewise(u<v,ee,ee+10)], u=0..1, v=0..2*u);


restart;
S:=proc(u,v) 10*u^2+20*u*v+15; end proc:
p:=proc(u,v)
    if not ( u::numeric and v::numeric ) then
      return 'procname'(args);
    end if;
    if u<v then
      S(u,v);
    else
      S(u,v)+10;
    end if;
end proc:
plot3d([40*u,80*v,p(u,v)], u=0..1, v=0..2*u);

Apply the procedure to some name(s).

Maple is telling you, correctly, that it cannot cast an unassigned name to a hardware double-precision floating-point number.

And your command instructs Maple to convert every element of K to a double-precision float.

Do you think that the name actually has a value which should evaluate to a float?

Is there some possibility that there are two similar names in play (perhaps a copy and paste mismatch of atomic identifiers)? It's hard to be more specific if you don't bother to upload a worksheet that exhibits the problem.

I'm not really content with having to break up the original condition, let alone the speed, but...

kernelopts(version);

   Maple 2017.0, X86 64 LINUX, May 17 2017, Build ID 1231047

sol:=CodeTools:-Usage(
       SolveTools:-SemiAlgebraic(
         { evalc(abs(a+b*I+3-2*I))^2 =(K1)^2,
           evalc(abs(a+b*I-3-8*I))^2 = (K2)^2,
           K1>=0, K2>=0, (K1+K2)^2=(6*sqrt(2))^2},
           {K1,K2} ) ):
memory used=47.74GiB, alloc change=1.12GiB, cpu time=8.79m, real time=5.81m, gc time=4.39m

sollist:=PiecewiseTools:-ToList(sol):
bettersol:=solve(Or(seq(sollist[i,1],i=1..nops(sollist)-1)));

       bettersol := {a = b - 5, 2 <= b, b <= 8}

expr:=eval(evalc(abs(a+b*I)),op(1,bettersol));

                            2    2 1/2
            expr := ((b - 5)  + b )

brng:=`..`(op([2,..],convert(And(op(2..3,bettersol)),RealRange)));

                   brng := 2 .. 8

simplify( [ minimize( expr, b=brng, location) ] ):
op(1,%), op([2,1,1,..],%), eval(op(1,bettersol), op([2,1,1],%));

                1/2
             5 2
            ------, b = 5/2, a = -5/2
              2

simplify( [ maximize( expr, b=brng, location) ] ):
op(1,%), op([2,1,1,..],%), eval(op(1,bettersol), op([2,1,1],%));

                 1/2
               73   , b = 8, a = 3

Use procedures as much as possible. Have the procedures be exports of a module. Keep all the procedures' sources (including those for all module members, whether locals or exports) in individual plaintext files, and keep the module's source in another text file. Use the $include directive to reference the module-members' sources from within that of the parent module.

That way all our procedures are defined in separate plaintext files, and they can all be used with full revision control. (Over the last 20 years I have used at least 4 different revision control systems on large Maple projects, with all the source in text files. Mostly unix/linux/cygwin. )

Next, write a short bit of code that uses the Maple `read` command, which pulls in and interprets all the above (e.g. read the master module defn file). This can build everything in a few lines. Optionally a separate short command can savelib the modules to ".mla" Library archive.

If you like you can make regular use of the $define directive at each text file's head, to specify common keywords. I do this to keep all references to other, stock package exports (e.g. LinearAlgebra) terse. You can even put such stuff in "include files".  

I keep module defns in text files with extension ".mpl", and module members (local or exported procedures or submodules) in text files with extension ".mm", and other included common stuff in files ".mi".

Of course, all the files then have their own revision histories.

All the above makes my Maple project development scheme match that of my C/C##/etc projects, at least as far as "action code" goes.

You wrote "application". Does that mean an assembly of interactive components? For that kind of application I now generate the full worksheet and its components programatically, using text files there too. So my project's graphical interface bits are revision controlled just like my project's engine bits.