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

@Nicolai408 I try to not use assume , because it can get difficult. Often I find I can achieve my goal by using just assuming instead.

I believe that assuming was intended to relieve some of the awkwardness of handling assume.

@awass 

At one point you mentioned pasting in the content. I was trying to ascertain the source for that, amongst other things. But now you claim all is *typed* into the Maple GUI. That's a contradiction.

So what keys stroke combination are you using to get the new lines, in the same Execution  Group, I was wondering.  In at least one of your examples there are three lines of code, where the parser is complaining only about the second line split. I was trying to figure out if the typed/pasted input (special character) for a line split is always the same for you.

I say that because this is OSX, and because I've seem some weirdness on OSX and plaintext in Maple before, and because OSX does weird things with LF/CR, I thought I'd try and narrow down exactly what was entered (typed or pasted).

I'll note that I've never seen this exact complaint before, even from other Mac OSX users. Yet it seems like a hint to me, that OSX boxes can have Enter and Return mapped weird, compared to other OSes. My last three comments have been about this. I feel like this conversation is an uphill battle for exact details. I give up.

@awass Yes, it was already clear what sort of thing was in the file.

But that's not what I've been asking.

Since I have no problems ever pasting in what your last Comment shows, I have a slight suspicion that you may be working from a text file that contains some special hidden character.

It's just a guess.

I can only check if I can download the actual text file, rather see its contents reproduced here inline.

@Carl Love I do not use ProcessClock, because I find its behavior unclear and inconsistent. I much prefer to use time[real] when measuring wall-clock performance.

Here is some behavior that I don't see clearly documented or explained. In this first attachment there is evidence that Now(ProcessClock) acts quite a bit like time() in the sense that it is reporting the total (added) CPU time resources of subthreads. I also contrast that with the behavior of time[real]() here.

But in this same worksheet there is an example that seems to illustrate that kernel threads spawned by Threads:-Sleep don't contribute to a matching increment in Now(ProcessClock). Again, this is more like I'd expect from time() than time[real]().

ProcessClock.mw  (I run this with the !!! triple exclam icon in the GUI's main menubar.)

But in this second attachment I simply have some calls to Now(ProcessClock) in separate execution groups. I execute this worksheet by waiting a few seconds, between hitting <Enter> directly, on the input lines. Here I see the results from ProcessClock go up in a manner close to the duration I wait between execution of different statements. So, to me, this seems more like behavior analogous to that of time[real]() rather than time(). But that seems to contradict the earlier evidence to the contrary.

ProcessClock_wall.mw

The behavior of ProcessClock seems inconsistent, and not at all well documented.

@awass I was trying to say that what might be germane (perhaps in an OSX specific way) is a plaintext file who's content matched what you pasted into maple. Not the plaintext 1D or typeset 2D .mw file.

I have a suspicion that what is getting pasted into the Maple GUI may contain the key difference.

@Ramakrishnan Sorry, but I don't understand what you're trying to say.

@Ramakrishnan When I execute your worksheet in my Maple 2018 it runs fine, and t1 gets assigned a numeric value in the first line, and it all seems in order. Please try again. Maybe you're doing something weird.

@Ramakrishnan As I mentioned, the nature of the animation wasn't you main difficulty or issue. You wanted to know how to make it play, programmatically. So I added the SetProperty call and added it to your code (and for which you seem to have thanked Tom).

@wlferguson19 I don't understand what you mean. The pair [x,y] = [sin(3t),cos(3t)] parametrizes a circle, which doesn't intersect itself (leaving alone the originating point, or points following overlap, from discussion).