@minhhieuh2003 I have a hard time understanding you, since you don't state your question with full sentences. So I have to guess.

I am guessing that you are asking how to generate a representation, from a given expression, which displays in typeset 2D Output form.  So look at how foo1, foo2, foo3, and foo4 are displayed below.

I only used a forced mtext above, because you were asking about numbers and simple text. You can get representations for other expressions using Typesetting commands (as you did originally in your own code) or InertForm commands.

Download TS_fun.mw

You seem to be interested in laying out text and expressions in a particular format. Have you considered using the DocumentTools:-Tabulate command? Or, if that is not flexible enough for you, the commands from the DocumentTools:-Layout package? Unlike these Typesetting commands, those have Help pages. It's just an idea...

@shimaa sadk This one works for me.

Download ask_new.mw

Another way is to force method=_d01amc the NAG function for semi-infinite domain, while preventing evalhf mode (so as to avoid overflow) as well as specifying a higher working precision both for integrand evaluations as well as internal handling of same. This is fast.

Download ask_new_faster.mw

@Ramakrishnan Please pay closer attention. The line that you claim is missing a statement terminator is not input. It is just the echoed output of the previous input line.

And the messages about long output are not an indication of a problem with the code.

Here is the Original Poster's code, with that output line removed, and some colons to suppress the printing of long itermediate structures. It works fine, in Maple 2018.

restart; with(VectorCalculus): with(Student[LinearAlgebra]): with(plots):
v[i] := 145000; thetabn := (1/8)*Pi; thetavn := (1/6)*Pi; k := 10; omegac := .5;
lrange := 6*Pi;
v[b] := cos(2*thetabn)/cos(thetabn); v[g] := sin(2*thetabn)/cos(thetabn);
n := `<,>`(k*cos(thetabn), k*sin(thetabn), 0);
vr:=
[v[b]*t, v[g]*sin(omegac*t)/omegac, v[g]*cos(omegac*t)/omegac];

lambda := v[i]*cos(thetavn)/cos(thetabn);
shockplot := PlanePlot(n, caption = "", planeoptions = [colour = blue, transparency = .5], normaloptions = [shape = cylindrical_arrow, colour = red]):

t1 := textplot3d([k*cos(thetabn), k*sin(thetabn), 0, 'n'], align = above):
B := animate(spacecurve, [[t, 0, v[g]/omegac], t = lrange .. A], A = lrange .. 0, axes = normal, thickness = 3):
C := animate(plot3d, [[v[b]*t, v[g]*sin(omegac*t)/omegac, v[g]*cos(omegac*t)/omegac], t = 0 .. x], x = 0 .. lrange, axes = normal, colour = red, labels = [" ", zeta, xi], thickness = 2, paraminfo = false):
reflection := display([B, display(op([1, -1, 1], B), C)], insequence, scaling = constrained, axes = normal, tickmarks = [0, 0, 0]):
display(shockplot, t1, reflection, axes = none);

If you have similar variations on this question then please add them here in a Comment/Reply to the original Question, instead of making a new and separate Question thread.

@brian bovril Your worksheet has two lines with identical input,

   combine(BS*FIT*pt*Unit(year),units);

One of those has a forced Units formatting of the output, to USD. So that is why that lines shows output in USD but the other identical line shows output in AUD.

You can see the Units formatting on that particular output by right-clicking on the output, and then selecting Convert Output Units... in the popup menu. Your worksheet had it set to system SI and units USD. If you check the radio button No Conversion then that forced effect goes away.

@Carl Love Those are taken from the analogous HTML tags for tables, I believe.

Eg, <tr> for table row, <td> for table data.

I don't know which other analogous tags are supported.

Another way to approach this problem would be to use DocumentTools:-Tabulate or, if that didn't allow fine enough control over horizontal alignment, to build up a simple procedure using DocumentTools:-Layout commands. These are ways to embed GUI Tables.

The Typesetting way is fun, though. I saw those mtable,mtr,mtd exports in use in a Calculus1 tutor, for placing multi-line, aligned output inside an embedded MathContainer.

This is already an unnecessay duplicate in a theme posted by this member. It's not helpful to separate the Question threads from each other.

Please, no more separate posts/questions of this.

I am in agreement with Carl. There are very few tasks which require programmatic analysis to get the `op` spec. and which can do that robustly.

Most of the few places where that is done (that I know of) are searching for the location of a particular kind of structure like a function call by a specific name. And those mostly use op for some additional reason.

Giving us more detail about the specifics of the task, such as the goal and constraints, would help.

@Rouben Rostamian  The GUI rendering implementation, or the changes to the various export plot driver, or the Library code tweaks to accept the new syntax and make sure nothing chokes on the new data structure form, or the documentarion edits, may not be complicated.

But finding people free to do all of those, and coordinating it, and convincing middle management that it should be top of the stack, could be tricky.

@Carl Love 

(A,B):= LinearAlgebra:-GenerateMatrix(liseq1, lisvar1):
X:=LinearAlgebra:-LinearSolve(A,B,method=LU):
LinearAlgebra:-Norm(A.X-B);
                               0

Xqr:=LinearAlgebra:-LinearSolve(A,B,method=QR):
LinearAlgebra:-Norm(A.Xqr-B);
                               0

LinearAlgebra:-LinearSolve(A,B,method=solve):
Error, (in LinearAlgebra:-Modular:-IntegerLinearSolve) invalid arguments to iratrecon

LinearAlgebra:-LinearSolve(A,B);
Error, (in LinearAlgebra:-Modular:-IntegerLinearSolve) invalid arguments to iratrecon

The method=solve option makes LinearSolve convert back to explicit equations and then pass to solve. The method=LU option does the steps as you did, involving LUDecomposition. The default behavior of LinearSolve depends on the domain of the entries.

Since you have completely edited your question and rudely removed the considerably larger original, I delete my Comment.

Your procedure new_print_F is not thread-safe. And very likely neither is CodeGeneration[Fortran].

@mmcdara 

restart;
numThrows:= 10^5:
r:= rand(1..2):
CodeTools:-Usage( Vector[row](numThrows, i->["H","T"][r()]), iterations=200 ):
memory used=0.77MiB, alloc change=26.80MiB, cpu time=25.42ms, real time=25.42ms, gc time=145.43us

restart;
numThrows := 10^5:
choices := ["H","T"]:
r := rand(1..nops(choices)):
CodeTools:-Usage( Vector[row](numThrows, i->choices[r()]), iterations=200 ):;
memory used=0.77MiB, alloc change=26.80MiB, cpu time=24.93ms, real time=24.93ms, gc time=147.12us

restart;
numThrows:= 10^5:
r := rand(0..1):
CodeTools:-Usage( subs({0="H", 1="T"},
                        rtable(1..numThrows,i->r(),subtype=Vector[row])), iterations=200 ):
memory used=1.53MiB, alloc change=58.80MiB, cpu time=21.64ms, real time=21.26ms, gc time=870.44us

Above, I see better behavior using the initializer i->r() instead of just r itself, which seems weird.  This is on 64bit Linux.

I believe that there was a time when rtable(...,random(...)) was faster than using an initializer. (I recall suggesting rtable and frandom to Joe, many years ago.) My experiments seem to show the opposite now.

However, with ideas of Carl,

restart;
numThrows:= 10^5:
CodeTools:-Usage( rtable(1..numThrows,
                         [seq("TH"[x], x=rtable(1..numThrows,random(1..2)))],
                         subtype=Vector[row]), iterations=200 ):
memory used=3.82MiB, alloc change=58.80MiB, cpu time=16.32ms, real time=15.56ms, gc time=1.78ms

I have deleted your duplicate submission about solving this system (with the typo corrected).

It works for me, using Maple 2018.0 or Maple 2018.2, in either 1D or 2D input mode.

Does your Maple otherwise work OK?

Do you have an initialization file? Are there additional locations in libname? Do you use a language pack?

If your Maple 2018 otherwise works OK, then it might be interesting to see if CodeGeneration worked if you disabled any initialization file or extra locations in libname.