@Markiyan Hirnyk It's extremely easy to fix it for Maple 13. Just swictch around the R and M declaration/assignments, and have the R be done in terms of M rather than MM.

After such an edit, pvbik's code could become,

M := Matrix(18, 1, [2, 3, 3, 5, 7, 8, 12, 5, 9, -3, 4.1, 7, 7, 7, -3, 9, 3, 8]):

MatLabSort := proc( MM :: Matrix ) :: list( Matrix, list );
local  i, Pos,
    SortedMM := table(),
    M := convert( MM, list ),
    R := convert(Statistics[Rank](M),list);
    
    for i from 1 to nops(R) do
        SortedMM[ R[i] ] := M[i];
        Pos[ R[i] ] := i;
    end do;
    
    return [ convert(convert(SortedMM,list),Vector), convert(Pos,list) ];
    
end proc;

MatLabSort( M );

Or one could use Statistics[Rank](ArrayTools:-Alias(MM,[op([1,1],MM)])), to avoid that inefficiency of the list conversion.

It would be better without the conversion of M to an Array, via list conversion. That's a double copy, with both as unnecessary inefficiencies.

In Maple 15 and 16, the Statistics:-Rank function accepts the 18x1 Matrix. But that won't work in all older versions, such as Maple 13 for example.

In Maple 13 (and later) you could do it like this and avoid that data copying,

restart: interface(rtablesize = 20):
M := Matrix(18, 1, [2, 3, 3, 5, 7, 8, 12, 5, 9, -3, 4.1, 7, 7, 7, -3, 9, 3, 8]);
with(Statistics):
A:=ArrayTools:-Alias(M,[18]);
R := Rank(A);
OA := OrderByRank(A, R);
NR := OrderByRank(Array([`$`(1 .. 18)]), R);
[OA, NR];

acer

It would be better without the conversion of M to an Array, via list conversion. That's a double copy, with both as unnecessary inefficiencies.

In Maple 15 and 16, the Statistics:-Rank function accepts the 18x1 Matrix. But that won't work in all older versions, such as Maple 13 for example.

In Maple 13 (and later) you could do it like this and avoid that data copying,

restart: interface(rtablesize = 20):
M := Matrix(18, 1, [2, 3, 3, 5, 7, 8, 12, 5, 9, -3, 4.1, 7, 7, 7, -3, 9, 3, 8]);
with(Statistics):
A:=ArrayTools:-Alias(M,[18]);
R := Rank(A);
OA := OrderByRank(A, R);
NR := OrderByRank(Array([`$`(1 .. 18)]), R);
[OA, NR];

acer

@Markiyan Hirnyk He posted plaintext, not 2D Math in a worksheet. Your mistake is in pasting it -- as is -- into the Standard GUI while in 2D Math mode. This code is an example of how the two parsers can differ. The source he posted is valid 1D Maple notation source (for Maple 15 and 16, at least), but it cannot be successfully run after being just pasted into the Standard GUI in 2D Math input mode.

The difference lies in how the 2D parser fails to handle the local variables' combined declaration/assignments (also split across lines). See here for an old post about some such differences.

If pasted as plaintext souce code into a Maple 15 or 16 interface prepared for 1D Maple notation source code then it runs.

@Markiyan Hirnyk He posted plaintext, not 2D Math in a worksheet. Your mistake is in pasting it -- as is -- into the Standard GUI while in 2D Math mode. This code is an example of how the two parsers can differ. The source he posted is valid 1D Maple notation source (for Maple 15 and 16, at least), but it cannot be successfully run after being just pasted into the Standard GUI in 2D Math input mode.

The difference lies in how the 2D parser fails to handle the local variables' combined declaration/assignments (also split across lines). See here for an old post about some such differences.

If pasted as plaintext souce code into a Maple 15 or 16 interface prepared for 1D Maple notation source code then it runs.

@Dragonsoul02 This complicated process seems sensitive to the maxstep done during the final dsolve. I'v adjusted that and got results in which O2r does not become negative (which I presume is physically impossible in the system that this attempts to model).

dsparint4.mw

I also tried to adjust some relative tolerances, along the following "rule". If A calls B (possibly many times) to compute a numerical approximation then the accuracy of each B result should generally be at least as good as the accuracy for which A is striving. Ie. you cannot make a silk purse from a sow's ear. Hence, I made the numeric interagtion step's `epsilon` accuracy tolerance be tighter than the `relerr` of final dsolve. And I made the `relerr` of the innermost dsolve be tighter than the numeric integration. Hopefully, this makes sense.

The attached worksheet takes longer than before. It now takes 360 sec to get to t=48 on my MS-Windows i7 machine, while my earlier inaccurate version took only 60 sec. The curves are also nice and smooth now, when plotted in Maple 15, giving more credence. And the results no longer disagree quantitatively, between Maple 15 and 16. The Maple 16 plot is a bit more jagged, but along the same paths. This revision seems a fair tradeoff, or speed for accuracy. (Incidentally, it only takes 280 sec on a 64bit Linux i5. Maybe dsolve numeric's engine could be produced with a better compiler.)

The whole scheme, involving parameters, seems to have pitfalls. That is: make the wrong adjustment and it takes forever to calculate, or set some tolerance poorly and the result is very inaccurate. And then there are the weird things, such as trying to redo any of it (except the plots) without a restart. I suppose that you had considered trying to roll the entire process into a larger system (according to calculus) with the hope that dsolve/numeric could resolve any accuracy requirements entirely on its own. Also, I have not experimented with other dsolve/numeric solvers for the final outermost stage.

@Dragonsoul02 This complicated process seems sensitive to the maxstep done during the final dsolve. I'v adjusted that and got results in which O2r does not become negative (which I presume is physically impossible in the system that this attempts to model).

dsparint4.mw

I also tried to adjust some relative tolerances, along the following "rule". If A calls B (possibly many times) to compute a numerical approximation then the accuracy of each B result should generally be at least as good as the accuracy for which A is striving. Ie. you cannot make a silk purse from a sow's ear. Hence, I made the numeric interagtion step's `epsilon` accuracy tolerance be tighter than the `relerr` of final dsolve. And I made the `relerr` of the innermost dsolve be tighter than the numeric integration. Hopefully, this makes sense.

The attached worksheet takes longer than before. It now takes 360 sec to get to t=48 on my MS-Windows i7 machine, while my earlier inaccurate version took only 60 sec. The curves are also nice and smooth now, when plotted in Maple 15, giving more credence. And the results no longer disagree quantitatively, between Maple 15 and 16. The Maple 16 plot is a bit more jagged, but along the same paths. This revision seems a fair tradeoff, or speed for accuracy. (Incidentally, it only takes 280 sec on a 64bit Linux i5. Maybe dsolve numeric's engine could be produced with a better compiler.)

The whole scheme, involving parameters, seems to have pitfalls. That is: make the wrong adjustment and it takes forever to calculate, or set some tolerance poorly and the result is very inaccurate. And then there are the weird things, such as trying to redo any of it (except the plots) without a restart. I suppose that you had considered trying to roll the entire process into a larger system (according to calculus) with the hope that dsolve/numeric could resolve any accuracy requirements entirely on its own. Also, I have not experimented with other dsolve/numeric solvers for the final outermost stage.

@Markiyan Hirnyk I indicated in my answer that I didn't expect using the dot product to be relatively efficient. I had hoped that, by qualifying it right there in my answer, attentive readers would be able to anticipate the consequential effect on relative timings involving many repetitions.

I wasn't really joking, no. I was trying to make a suggestion that was simple to use in the case that not many similar repetitons were to be done.

Perhaps we can find something else interesting to take from this. Here's a fun example, albeit involving floating-point data (which the original example did not),

> A:=<1e15,1,-1e15>:                                                           
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      1.

> A:=<1e17,1,-1e17>:
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      0.

The point is not that the dot product is more careful in general.

@Markiyan Hirnyk I indicated in my answer that I didn't expect using the dot product to be relatively efficient. I had hoped that, by qualifying it right there in my answer, attentive readers would be able to anticipate the consequential effect on relative timings involving many repetitions.

I wasn't really joking, no. I was trying to make a suggestion that was simple to use in the case that not many similar repetitons were to be done.

Perhaps we can find something else interesting to take from this. Here's a fun example, albeit involving floating-point data (which the original example did not),

> A:=<1e15,1,-1e15>:                                                           
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      1.

> A:=<1e17,1,-1e17>:
> add(x, x in A);
                                      0.

> A . <1,1,1>;
                                      0.

The point is not that the dot product is more careful in general.

Please upload the worksheet or paste the commands in plaintext 1D Maple notation inside a new Comment here, so that we can run it without having to type it all in ourselves and also so that we can reproduce your results. See the green up-arrow, to upload.

acer

@serena88 Put all the (38) names to which you have assigned all 38 equations into a list. Then build a new list of (38) new names to which you have applied the fnormal command. You can use the `map` command for that, or build it with `seq` (or even with a loop, if assigning to table entries).

Don't try and get the GUI to merely suppress the full display (elision) -- your program should be mathematically robust, so don't try and fake that with mere appearance. Make it robust, so that you truly know what is going on, and such actions are deliberate. Also, don't try and solve this by reducing Digits to some small value. Compute at necessary working precision (Digits) and  apply evalf[d] or fnormal command as necessary.

Trying shortcuts will undermine the correctness of your code.

@serena88 Put all the (38) names to which you have assigned all 38 equations into a list. Then build a new list of (38) new names to which you have applied the fnormal command. You can use the `map` command for that, or build it with `seq` (or even with a loop, if assigning to table entries).

Don't try and get the GUI to merely suppress the full display (elision) -- your program should be mathematically robust, so don't try and fake that with mere appearance. Make it robust, so that you truly know what is going on, and such actions are deliberate. Also, don't try and solve this by reducing Digits to some small value. Compute at necessary working precision (Digits) and  apply evalf[d] or fnormal command as necessary.

Trying shortcuts will undermine the correctness of your code.

There's quite a bit of interesting new functionality for managing colors in Maple 16's ColorTools package.

Here is a small example. (This is a chopped screenshot, since maplenet or whatever is used to inline worksheets into posts got it pretty wrong.) See the download link at the end.

colors.mw

acer

@mah00 I could be mistaken, but I believe that this is why DEtools:-phaseportrait did not show a direction field plot in your previous attempt as well,

> DEtools[autonomous]({DE[]},[x1,y1],t);

                             false

> DEtools[autonomous]({DE[]},[x2,y2],t);

                             false

See the Description sections of the help-pages for phaseportrait and DEplot. I don't see how it could be done with the fieldplot command either, for this system. Perhaps someone else could confirm or disprove.

@mah00 I could be mistaken, but I believe that this is why DEtools:-phaseportrait did not show a direction field plot in your previous attempt as well,

> DEtools[autonomous]({DE[]},[x1,y1],t);

                             false

> DEtools[autonomous]({DE[]},[x2,y2],t);

                             false

See the Description sections of the help-pages for phaseportrait and DEplot. I don't see how it could be done with the fieldplot command either, for this system. Perhaps someone else could confirm or disprove.