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.

Are you looking for purely real-valued solutions?

Providing bounds you might know for the any of the variables could also help.

@awass The compact option is part of the calling sequence, and it is shared by several similar commands for constructing Matrices with special indexing functions. But their structures consist of other things than that keyword.

Some stock indexing functions allow the Matrix to consume only a small constant amount of memory resources. Essentially, they can have "empty" storage, where values are only generated from the indexing function when entries' values are evaluated.

Multiplying a Matrix with  the "identity" indexing function by a scalar could, in principle, result in the Matrix with the corresponding "scalar" indexing function. It happens that nobody has implemented this.

So, in the following example, multiplying Matrix Id5 by 2 could in principle result in a Matrix like S. When such special case implementation is absent the result is a full rectangular Matrix. (Naturally, the result couldn't still have the "identity" indexing function.)

Download awass_ScalarMatrix.mw

There are rather many such special cases, across all stock indexing-function mixtures, and not all are implemented.

The system is reasonably flexible. It is even possible to have a Matrix with a gate-keeping indexing function as well as full rectangular storage.  (Full storage turns out to be useful as an easy way to get to fast external compiled high-performing functions from the Intel MKL LAPACK).

Why do you want to use the Trapezoid Rule for this?

@awass This is a separate issue.

You can use the compact=false option to the IdentityMatrix constructor, if you do not want it to have its gate-keeping indexing-function.  See also the Help page for that command.

Download awass_IdentityMatrix.mw

@Carl Love I should have read the documentation more carefully.

Above, I surmised that Now(ProcessClock) acts like time(), ie. as a measure of CPU time.

And a little further testing indicates that a better comparison against time[real]() would be a call like Now(SystemUTCClock).   SystemUTCClock.mw

And, as I now see by reading, that's pretty much in agreement with the documentation.

So the OP's original comparison between time[real]() and Now(ProcessClock) is not appropriate. Amongst other things, the former of those will be affected by the machine load, and the time it takes for the GUI to parse 2D Input and print results, etc. And in the presence of multi-threading it would be like comparing apples and oranges.

And, as mentioned earlier, comparison between two analogous mechanisms can hardly be expected to match better than the average variation of one mechanism by itself.

@vv The procedure ArrayTools:-Alias replaces its own definition when it first runs.  In older versions of Maple it was not possible to store a call_external properly in a .mla archive, hence this bootstrapping approach was devised. In StringTools a similar thing was done. Some packages replace several such exports, in one shot, in their ModuleLoad.

This preliminary replacement is not thread-safe. Yet a race/clash need not always occur. So, sometimes the error you've shown will attain.

A workaround is to compute some trivial example with ArrayTools:-Alias, before attempting the Thread computation that involves commands that use ArrayTools:-Alias.

restart;
showstat(ArrayTools:-Alias);

 ArrayTools:-Alias := proc()
   1   userinfo(4,'ArrayTools',`initializing external call for Alias`);
   2   unprotect(:-ArrayTools:-Alias);
   3   :-ArrayTools:-Alias := LinkExternal('alias');
   4   protect(:-ArrayTools:-Alias);
   5   userinfo(4,'ArrayTools',`external Alias call successfully initialized`);
   6   procname(args[1 .. nargs])
 end proc

V:=Vector[row](10,i->i):
Vf:=ArrayTools:-Alias(V,[2,5],Fortran_order):

showstat(ArrayTools:-Alias);

 ArrayTools:-Alias := proc()
    1   call_external(0,140237981471024,true,false,args)
 end proc