@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.

@rsweet Yeah, I think that it's too many terms.

As an interesting aside, irrespective of the bug in limit---and at the risk of stating the obvious: If we define the limit function

B:= x-> Sum(s(2^n*x))/2^n, n= 0..infinity),

then this is a Weierstrass type fractal: a continuous nowhere differentiable function. The 2^n in the denominator makes it easy to prove it continuous, and the fact that s'(x) is always 1 or -1 (where defined) makes it easy to prove nowhere differentiable.

@jefryyhalim Note that to get Tom's symbolic solution, it's still essential that the "fudge factor" 1e-10 (which I called epsilon) be removed from your original code and /tan changed to *cot. I don't want you to go away thinking that that effort was for nought. When a problem like that "sticks out like a sore thumb" in the code, my first focus is removing that problem.

@acer Thank you so much for your very helpful comments, Acer!

1. Yeah, I thought that that random matrix took too long to generate. I didn't worry about it fixing it because it was just an example.

2. So, you're saying that my type declaration checks whether the Matrix is actually symmetric if it's not declared symmetric?

3. I realized that I was accessing in C_order, and I tried to adjust the algorithm for that, but it didn't work. I saw a time improvement, but the results were wrong. So, I'm eager to take a look at what you did.

[Later]

Now I've looked at what you did. Seems simple enough. Is there a good reason to convert the output to Fortran_order?

@acer I've traced is as far back as this erroneous result:

limit((frac(x) - 1/2)/(x - 1/2), x= 1/2),

which returns 0 even though it's clearly equal to 1.

@Desruim Yes, you're right that the period is 1/2. Apparently, I didn't follow my own proposition!, which is still correct. I will correct the text and look into that 0.

@Rouben Rostamian  Oh no, I totally missed seeing that 0!! I thought that the OP was asking why the derivative is 3. So, I spent all that effort to write a precise freshman-level explanation of why the derivative is 3... and now the OP is not likely a freshman.

I'll think about that 0.

My code above implements precisely the formulas on Slide #9 from the course notes that you linked: 

https://www.igpm.rwth-aachen.de/Numa/NumaMB/SS17/handouts/Handout20170516.pdf

Apparently, your professor calls this algorithm Cholesky-Verfahren.

Unfortunately, compiled Maple only allows some fairly "primitive" coding style. So, for example, you can't use add to do summation. There are two spots in the code where that would've been nice to have.