There is no (formal, legitimate) way to decrypt such files, nor should there be. One of these situations necessarily applies:

1. You want your colleagues to be able to read your source code. Then send them the source code.
2. You want your colleagues to be able to read your source code but you don't want any interlopers to be able to. Then send the source code encrypted by an external application.
3. You want your colleagues to be able to run BUT NOT read your code. Then follow Tom's Answer (send the libraries with Maple's internal encryption).

None of those scenarios require you or your colleagues to decrypt Maple's internal encryption.

You just need to add an op to your dsolve command:

dsolve({op(%), op(Initial)}, %%);

You remembered it for Initial, but not for the ODEs. The above will give you a massively complex symbolic solution, which is probably of no use to you. So, add keyword numeric and save the solution to a variable for later use:

Sol := dsolve({op(%), op(Initial)}, %%, numeric);

To address avoidance of such mistakes: I find %, %%, etc., useful for off-the-cuff computations, but I also find that they make making mistakes more likely. So, I remove them from my finished work. If the worksheet is worth saving, then it's worth deconstructing the % references (from my point of view).

Here are details regarding three points of my random prime generators---elaborate enough that I thought a new Answer is justified. The points:

1. I said before that it would be easy to modify the generators to efficiently draw multiple samples from the same interval. Actually, it's so easy that there's no point to not doing it, so both generators below operate this way.
2. I thought that it was obvious that my UniformRandPrime was uniform. Well, maybe it wasn't so obvious. Below is some emipirical evidence of uniformity.
3. It probably wasn't obvious that my procedures work quickly even when the set of primes being selected from is much too large to create. Below is evidence of that efficiency.

(Worksheet is in Reply below due to some bug in MaplePrimes.)

Your equation has two dependent (or functional) variables: x(t) and y(t). That means that there'll need to be a system of two differential equations in order to get a solution.

The line with the add commands should be (at least in the current version of Maple):

L:= (1/3)*h*(y(x[1])+4*add(y(x[i]), i = 2 .. N, 2)+2*add(y(x[i]), i = 3 .. N-1, 2)+y(x[N+1]));

The result, after evalf, should be 4354.742601 (as you got). If you get something else (not close) or an error, use this:

L:= (1/3)*h*(y(x[1])+4*add(y(x[2*i]), i= 1 .. N/2)+2*add(y(x[2*i+1]), i= 1 .. N/2-1)+y(x[N+1]));

I'm sure that this latter syntax will work in Maple 16. (Current Maple allows a third argument for add--the "skip"--just as you used h as a third argument for seq.)

You may compare your results with:

Student:-Calculus1:-ApproximateInt(y(X), X= a..b, method= simpson, partition= N);
evalf(%);

Also note that your function y(X) is equivalent to a hyperbolic cosine cosh(X/C).

Unit should be capitalized, not unit. But you probably don't need to set anything to access all 32 G from Maple.

Write each method as a procedure (proc(...)). Let's say that these procedures are named Jacobi, GaussSeidel, and SOR. For each, do 

CodeTools:-Usage(Jacobi(...)),

etc.

This returns the result of the inner procedure. The times and memory are printed as side effects.

If you're timing things that take "minutes", this should be sufficiently accurate. Some special care is needed to time very small things (say, < 0.2 seconds).

Algorithm:

1. Select points Xj at random in C. Discard any at distance <= R1 from X1. Continue until you have m-1 points.
2. Compute min pairwise distance among X2, ..., Xm. Call this eps1.
3. Compute min({|X1-Xj| - R1 : 2 <= j <= m}). Call this eps2.
4. Let all of R2, ..., Rm = min(eps1, eps2) / 3.

For each instance of beta(10) you need to put a space between the beta and the left parenthesis. 

The appropriate command is add, not sum. It seems that everyone wants to use sum, which is primarily for infinite, symbolic, and/or indefinite summation. If you have specific integer values of the index, use add. Yes, you could use quote marks, as suggested by NM, but the better solution is to use add.

Also, you should use eval instead of subs. It seems that everyone wants to use subs, a command which has no knowledge of mathematics.

add(eval(diff(x^2, [x$k]), x= 0), k= 1..2);

The linear system of equations is inconsistent. In particular, the coefficients of tau[1] and tau[4] are identical.

Situations where string manipulations are needed to perform mathematical operations are extremely rare. Your string work can be replaced easily by using eval to change exp, like this:

a:= exp(2*t);
b:= exp(1)^(2*t);
eval(a-b, exp= (x-> exp(1)^x));

Likewise, numeric operations are not needed to verify the equality of expressions; simplify can be used, like this:

answer:= 5*exp(7.5*t);
response:= 5*e^(7.5*t);
simplify(eval(answer-response, e= exp(1)));

or, better yet,

verify(answer, eval(response, e= exp(1)), simplify);

Note that these solutions still work even if the symbol e has not been used in the response. 

The situations that you described as "terrible computations" are unavoidable consequences of the rounding of decimal arithmetic. You'll find them in any system of decimal arithmetic, be it a computer program, a hand calculator, or pencil and paper. It's called loss of significance, or, more dramatically, catastrophic cancellation. You'll find umpteen hits web-searching either of these expressions.

The way to avoid this is to actually use your CAS as something more than a fancy calculator---replace numeric computations with symbolic ones.

A negative number to a fractional (or decimal) power is complex. You have (f '')^0.4.

You didn't try expand(res), which I think will work, possibly followed by simplify(..., symbolic).

Just answering on spec; not at my computer to test it.

Your code is correct, and should not give an error. I suspect an installation or licensing issue.