@dharr @vv

Thanks to both of you for your involvement.

Concerning the required precision I quite agree with @dharr , all the more that using en eigenvector decomposition does the job in a more efficient way (memory and  cpu time).
While this is not a bug per se, my feeling is that not giving MatrixPower the capability to perform this decomposition is a flaw.

Computing the square root matrix of symmetric positive definite (SPD) matrices is at the core of many statistical algorithms (I agree they are alternative ways to write them).
These SPD matrices are correlations matrices which, unless strong dependencies among the random variables, are even matrices with a relative low condition number.
It's common these matrices have dimensions of a few tens.
Here is an example with a matrix of dimension 50 (still a quite low value in factor analysis) MatrixPower  is about to become almost unusable:

Download Dimension_50.mw

@Carl Love 

The expansion of the expression in term of powers of cos(2) plus some other strange stuff.

For_fun.mw

@dharr 

I vote up.

@dharr 

Thanks Dharr for your comments and your procedure, which can be useful.

BTW, I agree that the initial question is not clear.

@Sphericalmoments  : A cycle basis is defined only on  UNDIRECTED graph (see https://en.wikipedia.org/wiki/Cycle_basis);
On the example provided by @dharr :

DG := Graph(`~`[convert](Edges(G), list)):
       DG := `Graph 5: a directed unweighted graph with 6 vertices and 12 arc(s)`

DrawGraph(DG): 
Cycles := CycleBasis(DG);

Error, (in GraphTheory:-CycleBasis) input graph must be undirected

@dharr : how many "directed" cycles (I guess the OP means "for a given path direction" ???) do we have?
Two

G := Graph({{1, 2}, {2, 3}, {3, 4}, {4, 1}, {1, 3}}):
Cycles := CycleBasis(G);
                     [[1, 2, 3], [1, 3, 4]]
ListTools:-Occurrences(3, map(numelems, Cycles))
                               2

or Six
[1, 2, 3], [2, 3, 1], [3, 1, 2], [1, 3, 4], [3, 4, 1], [4, 1, 3] 

... I will look at your problem on Thursday when I am teleworking (I looked at it and it will take me some time to work out an answer).

BTW, I saw errors in my original worksheet ;-(

@Kitonum  @C_R

The term within the parenthesis is not of the form required by the OP

Maple 2015  returns the closed form of this integral whatever the input mode (which both behave the same way)

int_warning_1D_2015.mw

int_warning_2D_2015.mw

@Carl Love 

Thanks!
I use the combinat package on regular basis but randcom never caught my eye.

@dharr 

I didn't know about _EnvUseHeavisideAsUnitStep, whose role is nevertheless clearly stated in Heavside's help page.

It indeed can be a usefull way to remove isolated points where the expression is undefined, but don't you think it's quite dangerous is used blindly?

Here is an example which describes the Coulomb's static friction model.
The piecewise function represents a physically correct model  (while extremely notional) of the variation of the friction coefficient c according to the relative slipping velocity at the contact point of two bodies.

f := piecewise(v < 0, -c, v=0, 0, v > 0, c)
            piecewise(v < 0, -c, v = 0, 0, 0 < v, c)

_EnvUseHeavisideAsUnitStep := false; 
convert(f, Heaviside); 
eval(%, v=0);
                             false
                      2 c Heaviside(v) - c
                        c undefined - c

_EnvUseHeavisideAsUnitStep := true; 
convert(f, Heaviside);
eval(%, v=0);
                              true
                      2 c Heaviside(v) - c
                               c

I do prefer the default _EnvUseHeavisideAsUnitStep := false which warns me that there will probablity face later some difficulties, than  _EnvUseHeavisideAsUnitStep := true which seems to say that there will be no problem at all and provides a wrong value at v=0.

For information the numerical treatment of problems invoking this Coulomb's model generally regularize the expression f by writting instead f := c*tanh(v/eps) where eps is a "small" positive number.

For the OP problem I believe that the first thing do do before removing the isolated points where the onverse Laplace transform i undefined, is to check if the left and rightlimites are equal (which happily happens to be the case here).

restart;
expr:=(s+exp(-Pi*s)-exp(-2*Pi*s))/(s*(s^2+2*s+2)):
y := inttrans:-invlaplace(expr,s,t):

limit(y, t=Pi, left), limit(y, t=Pi, right);
                              0, 0

limit(y, t=2*Pi, left), limit(y, t=2*Pi, right);
                    1 + exp(Pi)  1 + exp(Pi)
                    -----------, -----------
                     2 exp(Pi)    2 exp(Pi) 

I nevertheless vote up: for the simplicity of the trtick, even if I'm not convinced of its lack of toxicity

@tomleslie 

It's difficult to admit that Statistics:-AutoCorrelation and Statistics:-CrossCorrelation don't have consistent definitions (the former operates on a mean-shifted vector while the latter works with raw vectors) given that CrossCorr(V, V= = AutoCor(V) by definition.

I keep considering this inconsistency as an error of the same order than a confusion between moments and non centered moments.
But you are free to think otherwise.

@tomleslie 

You wrongly interpreted what you read here https://en.wikipedia.org/wiki/Autocorrelation.
You confused autocorrelation function and autocovariance function.

@Elisha 

Here is your file corrected
Please look to the parameters q__E (and not q[E]) and sv0 (shich appears as s__v*0 in 1D input).

in dsolve the option parameters requires a list of names, but in the "instanciation" of the solution (sol) parameters requires a list of values.
An alternative which avoids using the option parameters during the "instanciation"  is given  at the end of my reply.

Covid19_Simulation2-2_mmcdara.mw

@Carl Love 

Thank you Carl for this extremely interesting (ordered) set of explanations.

About point 4
The --setsort entry contains a lot of useful informations.
In particular the example s := {bb, aaaaaaaa} whose displayed order ("internal memory order " too?) is based on the length of the elements.
The --setsort option seems to be only avaliable through the Maple command mode, am I right?
Unlesswritting sort(convert(s, list), lexorder), would have been a way to impose the lex order on the set s?


About point 5:
I do remember sets ordered in a different way from one session to another. I even think this "nuisance" lasted a little bit longer than Maple 8.


About point 6:
I agreee.

The problem I submitted comes from the transformation of a system of ODEs of arbitrary orders into a system of first order ODEs alone.
The selection of the dependent functions (F) and the derivatives through which they intervene (DF) is descibed below (the system comes from a recent question on this site).
My algorithm to transform this system into a first order ODE system starts from the rightmost element of each set in DF an ends to the leftmost one, inrtoducing intermediate functions at each move.
But it didn't work due to the different "true" orders (by opposition to the "displaying orders") of each of these sets.
(I did otherwise meanwhile)

Download Origin.mw

@Carl Love 

Thank you Carl.