@jefryyhalim Your sigma is not 0; it merely appears to be 0 at the scale of the plot. To get a more-prescise numeric value, do

A(0);
      0.661316346230992e-2

Does that value make sense in the context of your problem?

@jefryyhalim Regarding the removal of small imaginary parts, I think that at least one of us has had a fundamental misunderstanding of what the other meant. I meant that they could be removed after they had been generated.  So my technique can't speed up the process by which they are generated. That's the part that's taking 5-10 minutes, right?

Regarding the numeric BVP solver, Rouben has provided an example above in the time since you asked. See if you can get that working. The BVP solver in this case is nearly instantaneous, and it doesn't give solutions with any non-real numbers. I think that it'll ultimately provide a more satisfactory overall solution to your problem than will symbolic solution. If you get any error messages from it, do not despair. There are many options for error control that we'll be happy to help you with. I used the option maxmesh= 2^14 for your problem (which is probably a lot more than is needed, but the solution is still nearly instantaneous, so I see no reason to not do it).

@Earl You can also abbreviate Transpose(U) as U^%T, without needing to load LinearAlgebra.

@Rouben Rostamian  This is a Reply to your previous two Replies. In the first, you said "it returns nothing, indicating that there is something wrong with your system." Symbolically solving for the integration constants in this system involves solving (algebraically) a massive system of transcendental equations that is generated by the BCs at the "other" endpoint, the one where the independent variable is not 0. The chances that such a system can be algebraically solved are virtually nil. I wouldn't call this "something wrong with your system." This same thing happens when using symbolic dsolve on all but the most-trivial BVP systems, so it's generally not even worth trying for a symbolic particular solution. You can fsolve for the coefficients after getting the symbolic general solution. Sometimes giving dsolve the option convert_to_exact= false combined with using decimals in the input system helps. 

In the second Reply, you suggest using dsolve(..., numeric) and specifying BCs at three values of the independent variable: 0, L/2, and L. The numeric BVP solver will immediately reject this: It strictly only allows BCs at the endpoints. Compare:

sys:= {diff(y(x), x$3), y(-1) = 1, y(0) = 0, y(1) = (1)}:
dsolve(sys);
dsolve(sys, numeric);

@Christian Wolinski Yes, I thought that you were thinking along the lines of atomic. That's slightly different. Rather than invariance under op, it's invariance under mapping of the identity function, so it's equivalent to

`type/Atomic`:= x-> evalb(x = map(x-> x, x));

I think that everything that's invariant under op is a "fundamental" type, by which I mean a structure that has a direct internal representation (and hence a dagtag  (see dagtag under ?kernelopts)). Of those that are first-class objects (look that up in Wikipedia), by which I means assignable to a variable at the Maple-language level, the only ones that I can think of that are invariant under op are integer, string, and symbol. So, you could use

`type/InvariantUnderOp`:= {integer, string, symbol};

However, this is less robust than the procedure-based methods that I advocated before because if a new fundamental type is added to Maple, then the categorical typespec immediately above will need to be checked and perhaps rewritten.

@Christian Wolinski Your objection to satisfies seems incredibly naive considering the relatively high level of skill in symbolic computation that you've otherwise shown here on MaplePrimes. What do you think "Maple types" are? Were they carved into stone tablets on Mt Sinai and given to Moses? No, they are all procedures that evaluate boolean conditions. Some of those procedures are builtin; most are explicit Maple library procedures named `type/...`. So, if you want it to be more like an official Maple type, just do

`type/InvariantUnderOp`:= x-> evalb(x=op(x));

and install it in the library. 

@jefryyhalim 

@@ is the functional iteration operator. Defining recursively,

(f@g)(x) means f(g(x)) (i.e., functional composition),
(f@@n)(x) (for n::integer, n > 1) means (f@(f@@(n-1))(x),
(f@@1)(x) means f(x), 
(f@@0)(x) means x (i.e., the identity function).

In some limited contexts (i.e., when Maple has been taught what the inverse of f is), 
(f@@n)(x) (for n::integer, n < 0) simplifies to (g@@(-n))(x) where g is the known inverse function of f.

The output of a function may itself be a function. These are sometimes called functional operators in the mathematical literature, but they're so easy to construct in Maple that a special name is not usually used for them. If F is a functional operator, then F(x)(y) means (F(x))(y), (i.e., the application of a function to its argument(s) is itself a left-associative operator). Such is the case with D, the differential operator. So,

D(f)(x) (for x::name) is essentially the same as diff(f(x), x), and
D(f)(a) (for a:algebraic, a::Not(name)) is essentially the same as eval(D(f)('x'), 'x'= a) (or f'(a)). So, for example, (D@@2)(f)(0) means (D(D(f)))(0) means f''(0).

Partial derivatives can be expressed in the functional D form also by applying an index to the D. For example, 
D[2](f)(x,y) means the first derivative of f with respect to its 2^nd-position argument (y in this case), which is essentially the same as diff(f(x,y), y), if x and y are distinct names. This indexing of D can be iterated: Defining recursively,
D[m,n](f) means (D[m](D[n]))(f), which is a second derivative (even if m=n). This indexed form of D can also be used for a univariate function, so D[1,1](f)(0) is another way to express f''(0).
 

@acer I'd expect it to resolve under the integration because the limits of integration contain the necessary information. Indeed, regardless of the presence or absence of assumptions, simplify applied to an unevaluated integral will use assumptions based on the limits. So:

restart:
Psi00:= exp(-r^2/2)/sqrt(Pi):
int(int(conjugate(Psi00*r^(1/4))*Psi00*r^(1/4)*r, r= 0..infinity), phi= 0..2*Pi);
#Above returns only partially evaluated.
simplify(%);

@Desruim What is your goal with this? 

Be careful with trunc(x) and frac(x) for x < 0. Especially for the latter, I think that a nonstandard definition is used. Certainly, if you want your functions s and b to be periodic on the whole real line, you'll need to make a small adjustment.

@vv I expect trunc and frem to have much less symbolic capability than the others (frac, round, ceil, floor) because it is built in.

@Markiyan Hirnyk I think that I see the problem that you're encountering. If I try to use the "tabs", those just take me back to general MaplePrimes. But if I click on "See all Questions by Rouben Rostamian", it works. 

Here are the links:

https://www.mapleprimes.com/users/36966/questions

https://www.mapleprimes.com/users/36966/replies

https://www.mapleprimes.com/users/36966/favorites

As far as I can tell, he has made no Posts.

Hopefully you can see the simple pattern in the link names.

@Markiyan Hirnyk Thanks for the clarification. All those links work normally for me. See if you can take this link to his Answers: https://www.mapleprimes.com/users/36966/answers

I don't understand what is meant by your statement "any search in his Posts, Questions, Answers, and Replies is linked with MaplePrimes only."

@mmcdara I am only stating here what's required by the "envelope" algorithm used by Statistics:-Sample, not any more-liberal requirements that may be used in a mathematical statistics context. In particular, this algorithm requires the PDF, not the CDF. From the evidence that I've seen so far, this envelope algorithm is very efficient, at least in Maple 2018.

Regarding your translation: I think that you've mistranslated inflection point. In general, this means a point where a function is continuous and over which its second derivative changes sign. In other words, it's a point where the function changes from concave to convex or vice versa. So, the stated requirements are that the function be twice diffferentiable at all points in its support (though I don't think that the endpoint behavior actually matters), and that there be at most finitely many of these inflection points.

@Mariusz Iwaniuk It is a general weakness of piecewise, not of inttrans. To avoid these problems, I recommend that whenever piecewise is used to express a function of a single real variable t (which is, of course, the most-common situation for using piecewise) that all the conditions be expressed in the form t %op V[k] where each %op is <, <=, or = and V[1] <= V[2] <= ... <= V[n]. This will be possible in the vast majority of practical cases, but perhaps not all. 

Note that each condition can tacitly use the assumption that all conditions to the left of it have been false. Thus junk with and conditons like this is never necessary:

piecewise(t < 1, t, t >= 1 and t < 2, t^2, 0);

I see that junk with and all the time. Usually it works, but it makes me cringe.