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

@Kitonum Indeed, Tom's suggestion is nice and straightforward.

Due to a logical dependency, and a very slight performance difference, perhaps the list of choices could be defined before r, and referenced in the Vector initializer.

restart;
randomize():
numThrows := 10^1:
choices := ["H","T"]:
r := rand(1..nops(choices)):
Vector[row](numThrows, i->choices[r()]);

@matthewdry I added a second Explore example, which pans/zooms a subsection of a larger resolution, fixed, starting image.

@radaar Did you understand what I meant when I wrote, "Help cannot be given for the parts you do not reveal to us"?

Nobody can answer your followup question properly unless they guess about the missing details, and get lucky.

Maybe you are trying to assign to entries of AA without first assigning it as a Vector/Matrix/Array, in which case it'd be a table.

But really I have no idea what "some evaluation" is going to be. Is it some floating point computation? Is it a computation that can run under evalhf?

What is the reason why you continue to not provide proper details? Why cannot you upload at least a representative portion that actually exhibits the memory or performance problem?

Please don't duplicate this query about extraction of (a subset of) the equations.

@tomleslie Those round brackets simply make Maple call the anonymous procedure (directly) with no arguments.