Obviously I cannot run your code - too many undefined quantities, but the following annotation may help

dummyfunction := proc(param1, characteristic):
sol := dsolve(sys,hello);
clock := Clock():
clock:-now(); #
                     # This will return the current system time as large integer
                     #
clock:-start(): #
                     # This will set the 'checkpoint' variable to the current time
                     # so that one can use module methods which will measure
                     # the elapsed time between this point and the point at which the
                     # method is called.
while not(rhs(sol[1][1])/rhs(sol[3][1]) = 1 or rhs(sol[1][1])/rhs(sol[3][1]) = -1)
         and
         clock:-elapsed() <= 5 do #
                                                # The first time this is executed, it will provide
                                                # the elapsed time since the clock:-start() method
                                                # was called. It will also stop the clock, so that
                                                # the second iteration of this loop will fail
                                                # For this to work on successive iterations of
                                                # this loop, use clock:-sample()<=5 instead: this
                                                # returns the elapsed time since the clock:-start()
                                                # method was called, and it does not stop the clock
sol := dsolve(sys,hello);
if length(convert(sol,string)) > previouslength then
 numberofincrease := numberofincrease + 1;
end if:
previouslength := length(convert(sol,string));
od;
return [numberofincrease, "max=3", length(convert(sol,string)), characteristic2, rhs(sol[1][1])];
end proc:

I can think of other ways to achieve the same end - just using the inbuilt command time() for example.

Probably neater would be to use the timelimit() command in a try/catch sequence see ?timelimit and ?try
 

For example the first assignment in your procedure, ie

H := add(H . i*lambda^i, i = 0 .. D)

is a recursive definition of H. It is essentially of the form H:=f(H)

Furthermore, it contains the sub-expression 'H.i' Now Maple interprets the '.' operator' as a non-commutative multiplication. Since 'i' is scalar in this expression, I'm not sure that this non-commutative multiplication willl ever be meaningful. So far as I can tell, Maple is ignoring the non-commutative aspect, and treating this as conventional multiplication, so with D=2, the right-hand side of the above expression evaluates to

Is that what you want/expect. If not, what exactly are you trying to achieve with this expression?????

Similar queries arise in other lines of your code: use of recursive definitions, spurious(?) use of non-commutative multiplication, use of undefined neutral operators (ie &*)

I really cannot work out what you are trying to achieve in this procedure

I doubt if anyone is going to work on this by retyping all of your code. Much better if you post a worksheet using the big green up-arrow in the Mapleprimes toolbar

Kitonum,

A multiplying factor of 'y' seems to have gone missing from the scond term of your second equation

The 8*8 matrix of integers at the top of your new worksheet cannot possibly be a valid distance matrix. It is symmetric, which is a necessary (but not sufficient) condition. Another necessary condition is that there be no triangle law violations, so M[i, k]<=M[i,j]+M[j,k] for all i, j, k.

Meeting both of the above conditions is still not sufficient. According to Wikipedia,(https://en.wikipedia.org/wiki/Euclidean_distance_matrix) a further necessary condition is that the Rank() of the matrix of squared-distances should be min(N,m+2), where N is the number of points, and m is the dimension of the space in which you are working (ie 2D). Assuming that you always have more than 4 points, then in 2D, the rank of a valid squared-distance matrix should always be 4.

If you check Rank(c^~2) on the example matrices in my original worksheet, it returns 4. For the 'new' matrix which you supply, Rank(c^~2) returns 8!!!

I have revised the code in the above so that

1. It now handles any number of 'cities' - the test example in tha new attached code uses 10 cities with random coordinates, You should be able to use any number of 'cities', provided that their coordinates are given as an n*2 matrix where n is the number of cities
2. Since your are dealing with 2-D coordinates, the number of non-zero eigenvalues for the *magic* matrix identified in the stackoverlow referencw *ought* to be two. These two "non-zero" eigenvalues are now selected as the largest two (absolute) values in the generated eigenvalue matrix - so unlike my earlier post, these do not need to be selected by 'eyeball'
3. Always bear in mind that starting from a 'distance' matrix, there are an infinite number of possible solutions for the coordinate values. Any translation, rotation, reflection (ie rigid tansformations?) preserves distance.. Hence returned coordinate values may not be (obviously??) meaningful
4. Added a check which evaluates the difference between the input" distance matrix and the "computed" distance matrix. In an ideal world all entries ought to be zero. In a "floating point" world all entries ought to very close to zero - which they are
5. I really wish I understood why this algorithm works: I have stared at it and played with it, but \i'm not getting it! Other suggestions on stackoverfow I do get: as in translate one point to the origin; rotate other points so that one lies on the x-axis; then multiple applications of the cosine law; conceptually I do understand this approach - but stackoverflow says it is "inefficient". Maybe I shouldn't worry too much about what I don't understand?

Revised code attached

revEngSol2.mw

All of these plots can be produced using the Maple commands implicitplot3d() and intersectplot() with appropriate options- see the attached.

somePlots.mw

So I'm missing the point of this post - a moderately complicated way to do what is pretty simple??

plot diff(theta(eta), eta) with respect to epsilon, then the attached worksheet contains the solution for this requirement and your original request

helpSol2.mw

Using
ImportMatrix("C://Users/TomLeslie/Desktop/Signal.txt",
                       source = delimited,
                       delimiter = " ",
                       datatype = float[8]
                    ):
takes 2.3secs. On my machine drive 'C' is an SSD. But if I relocate the file to a mechanical hard drive and repeat the above it takes ~2.5secs. So drive read/access time doesn't seem to be an issue

Using

readdata("C://Users/TomLeslie/Desktop/Signal.txt",
                   float
               ):

takes ~8.1secs plus ~0.2secs for convert(L0, Matrix)

In case it matters, I'm running 64-bit Maple 2016 on up-to-date 64-bit windows7 home premium.

NB the file you uploaded is 400001 rows by two columns : within Maple op(1, L0) returns 400001, 2, confirming the size. So nothing like the 10^6 * 10 in your original post. The latter would contain 12.5x more entries, so might take 12.5x longer than the above numbers??

try plotting your colorscheme function as a simple 2-D plot. So for example, the scheme you propose would be

plot(signum(z)*ln(abs(z))/sqrt(exp(abs(z))), z=-50..50);

Now LOOK AT IT!!! You don't want a color scheme based on that function. This has pretty negligible variation except for a small band around zero - so everything in your spectrogram is going to be pretty much the same color (except for the small band around zero!)

You (probably) want something which

1. varies smoothly as a function of z,
2. is monotonic
3. compresses the z-values somewhat

so look at the following possibilities

plot( [ signum(z)*ln(abs(z))/sqrt(exp(abs(z))),
          signum(z)*ln(abs(z)),
          signum(z)*abs(z)^(1/3),
          signum(z)*abs(z)^(1/5)
        ],
        z=-50..50,
        color=[black, red, green, blue]    
  );

It is fairly obvious that signum(z)*abs(z)^(1/5) gives the maximum "compression" as a function of 'z', and actually when I use it in your spectrogram, it looks reasonable. The drawback is that everything from -50..-5(approx) is going to be one color and evertyhting from 5(approx)..50 is also going to be one color, with significant variation only between about -5..5

However the nature of your data indicates that the majority of z-values are in the range -50..-30, so the "best" color scheme might be one which compresses this range, but does not compress the range -30..50, anything like as much, if at all.

So a "braindead" choice might be

colorscheme =["zcoloring",
                         z->piecewise( z<-30,
                                                 signum(z)*abs(z)^(1/5),
                                                 signum(-30)*abs(-30)^(1/5)+z+30
                                               )
                       ]

If you can't visualise this function, then just plot it on its own, as in

plot(piecewise( z<-30,
                          signum(z)*abs(z)^(1/5),
                          signum(-30)*abs(-30)^(1/5)+z+30
                        ),
        z=-50..50);

in order to see what I'm getting at.

This is probably the "best" coloring I have come up with (so far) for your spectrogram.

A caveat: choosing "trick" coloring schemes like this overemphasizes the variation in your spectrogram.

Graph is labelled incorrectly, although I'm pretty sure the cacluation is correct. Second label for graph should be

typeset((diff(f(eta), eta, eta))/(1-phi)^2.5)

in the method of using three for loops. Can't use the cartprod() statement I used previously, but it is relatively easy to use nested seq() statements to generate all parameter combinations, whihc I have done in the attached.

I have also changed the way Expr is defined and evaluated, in order to make it 'easier' to change

odeExpr4.mw

Having three loops is pretty much a "style" thing. I generally try to restrict myself to two, but I don't get paranoid about it. One way around this is to generate the "cartesian product" of three lists of loop indexes. Effectively this will produce all possible combinations of a,b,c in a sensible order. One can then cycle through these using a single loop. The attached shows how this can be done and generates a Matrix whose data in the same order as your previous post.

If you want the ordering to be as shown in Carl Love's response then just change the

ListTools:-Reverse(vals[nextvalue]())

command to

vals[nextvalue]()

odeExpr3.mw

but the following might be what you want??

It computes the solution of the ODE system for a pair of values a=loopIndex, b=loopIndex and evaluates it at x=1: then computes the value of the 'expression' using a=loopIndex, b=loopIndex, c=loopIndex.

Answers stored in a table indexed by loop variable

odeExpr2.mw

but raising a matrix to a power is not an elementwise operation- so why use zip?

As example, try

M:=Matrix([[1,3],[2,2]]);
M^3

As stated earlier, this sort of thing works in current Maple: in 8-year-old Maple, who knows?

BTW please stop making statements like " This is a trivial task in MATLAB". I know it is trivial in Matlab, because I've been using Matlab for ~25years. It is also trivial in Maple - at least for anyone who can read the help