@Fereydoon_Shekofte You don't need a computer to decode the string.  Doing it by hand is quite trivial and fast.  You can even do it in your head.  I will illustrate this by an example but the method is general.

The Arabic Cipher encodes the string ABCDEFG as DECFBGA.  To decode, read every other character in the encoded string, from right to left, beginning at the string's end (I have marked those characters in red):

D E C F B G A

That yields ABCD.  Then read the remaining characters from left to right.  That yields EFG.  Put the two parts together to get the decoded string ABCDEFG.  That's all!

Equivalently:

Read characters from right to left in the encoded string, and pile them into two groups, like this.

The first two characters read are A and G:
A  <−>  G

The next two characters read are B and F.  Insert them as shown:
AB  <−>  FG

The next two characters read are C and E. Insert them as shown:
ABC  <−>  EFG

The remaining character is D.  It can be inserted in either the left or the right group, doesn't matter which:

ABCD  <−>  EFG

Join the two groups to obtain the decoded string:
ABCDEFG

@vv I assume that by the Order of a permutation p you mean the smallest integer m>=1 so that p^m is the identity.

If so, then taking P[n] as you have defined, we seem to have order(P[n]) <= n.  I have checked that for n from 1 to 600.  I don't understand why you say Order(P[n]) >= n.

In particular:

1. Order(P[17]) = 12, that's why Fereydoon_Shekofte's example of applying the cipher to the string "FereydoonShekofte" (17 characters) recovers the original string in only 12 steps.
    
2. Order(P[42]) = 8, not 131072.
    
3. Order(P[995]) = 180, and not the enormous number that you have cited.
    

But perhaps I have misunderstood you.

@tomleslie The culprit is not the lack of brackets in the subs.  In the context of this question the presence or absence of the brackets is immaterial.  The problem lies in the first input line where the := assignment to f has been entered but not executed as is evident in that line's output.

Maple docs on the web are not reliable.  You shouldn't be learning from them.

I don't mean that they contain errors.  What I mean is that they have been obtained by translating Maple's native help pages into html and, as it happens with any translation, some significant parts can get garbled.

The web page that you have referred to says: "To define a derivative, use the diff command."  But then we see that there is no "diff" in the example that follows.  That part has been lost in translation.

So how to get around the problem?

After you get a bit more used to Maple, you will have no need to go to google for help.  Maple comes with its own built-in documentation and that's the preferred place to look.

However, if at this stage of your learning you prefer to look things up on the web, I offer the following advice.

The web page that you have cited documents Maple's "dsolve" command as you can see by looking at the very top of that page.  Once you know that it is "dsolve" that you are looking for, skip the web page and read Maple's built-in documentation on "dsolve".  The built-in documentation does not suffer from translation issues.

@acer May thanks for pinpointing the source of trouble and the suggested remedies.  Also thanks for submitting a bug report on this.

Additonally, since the complaint arises from odeplot, it would have been more user-friendly to have an error message of the sort
Error, (in odeplot) invalid range
instead of that shown.

I see at least two problems in your code.

The first is a Maple syntax issue.  You have
pdsolve({dsys, ics}, type = numeric);
That should be
pdsolve(dsys, ics, type = numeric);

The second is a math issue.  You have
ics:= {Q[1](0,0) = 0, Q[2](0,0) = 0, D[1](Q[1])(T[0],0) = 0, D[2](Q[2])(0,T[1]) = 0};

The first two of these four conditions look suspicious.  For the first one I would have expected something like Q[1](T[1],0)=0.  I don't see how you have arrived at Q[1](0,0) = 0.  Same goes for the second condition.

@vv Thanks for the illustration.  Actually I did not think of the Fourier series solution because the real problem I am interested in is more complex.  I provided the example in my post as a stripped-down case to demonstrate the numerical noise issue.

I can't tell how pdsolve,numeric handles boundary conditions but in the help page ?pdsolve,numeric, under the heading "Details", we read:

Note: A first order accurate accurate boundary condition (the default) can be used for second order accurate method, and still provide a solution of second order accuracy.

That statement bothers me.  It appears that pdsolve applies second order accurate finite differencing to the derivatives in the interior, but only first order finite differencing at the boundary.  That can let inaccuracies to creep in.

When I have the time, I will code a finite difference solver from scratch and compare its results to those of Maple's.

@DLESOS It's telling you that you haven't paid yet for the product.

Get a good copy from https://www.maplesoft.com/ but you need to pay for it.

I run Maple on Ubuntu Linux and I am not unhappy with the default look and feel.  Does it really look awful on Arch-Linux?  Post a screenshot to let people know what it is that you see.  It will also help if you describe what it is that bothers you.  Otherwise it is difficult to provide useful advice.

@Earl Since you said that you want to animate the solution, you may be interested in this which I am posting without its Maple code.

The help page on the sign function says

    The sign function works for polynomials with coefficients of type `numeric`.

Applying it to expressions other than polynomials goes against sign's intended purpose.

Despite what the legend says, the graph that you have shown is that of the tan function, not the inverse tan.

Moreover...

Tickmarks in the form of multuples of Pi makes sense on the horizontal axis but not on the vertical.

@vv That's a very nice .  It also explains why understanding that object is not so intuitive.

Consider these two objects:

#1. A thick/solid mobius strip printed on a 3D printer

#2. A construction of your drawing, made of paper

Object #1 is a one-sided surface in the sense that it's impossible to color it in two colors without discontinuities

Object #2 is a two-sided surface!  It can be colored continuously in red on the side of the paper to which the arrows are glued, and in a different color on the reverse side of the paper.

It's the dichotomy between #1 and #2 that makes it difficult making conclusions without a careful drawing such as yours.

@vv The mathematical zero-thickness mobius strip is certainly not orientable, and therefore it cannot have a continuous normal.  But a "thick" mobius strip is different.

If you follow the normal vector as it turns one round around the thick strip, it ends up in a point opposite its starting point but at a distance T away from it where T is the strip's thickness.  The vector's orientation is reversed but its point of application is not the same as that of the starting point, so there is no discontinuity.

If you continue traveling with that vector for another round, it will arrive at the starting point and regain its original orientation.

I have printed a few mobius strips on 3D printers.  They pose no difficulties.