@sand15 Since the OP said "discret uniform distribution", I interpreted the function as 1/(k+1), which I thought was the only reasonable interpretation under those circumstances. Since my code didn't directly use the function, I didn't comment on the typo (just as I didn't comment on "discrete" being misspelled "discret").

The method that you presented in your Answer is both correct and useful for arbitrary discrete distributions^[*1]. I have no problem with that. 

The point of my Answer is that for the specific and very common case of a discrete uniform distribution whose support is a range of integers, it is easy and the usual Maple coding practice to generate samples simply by using rand^[*2]. It may be possible to improve the efficiency a little by instead using RandomTools:-Generate. I think that the efficiency is reduced by using ProbabilityTable and Statistics:-Sample; however, I haven't tested that in Maple 2018, which may have introduced a substantial efficiency improvement for Sample used with custom distributions.

^[*1]Actually, I did just notice a problem with your method, which I just put as a Reply to your Answer.

^[*2]It is not as widely known as it should be that since the output of rand(m..n) for numeric m and n is a procedure rather than the random number itself, the following is an inefficient way to generate a sample of size N because it recreates that procedure for each number generated:
seq(rand(0...k)(), i= 1..N).
I didn't comment on this issue in my Answer (although I probably should have). Although my code handles this issue efficiently, it does so at the expense of some perhaps-unexpected complexity of the code.

@vv Those are great questions, and I was just about to ask similar questions myself, in a separate Question, as I just came up with the code in question today. The documentation of thismodule is very thin, and what I know is by expermentation. Surely its relationship to its parent module is much more complex than thisproc's relationship to its parent procedure; and surely its relationship to the :- and [] operators is more complex than other modules' relationship to those operators. And it usually can't be replaced by the named module that it refers to.

@shimaa sadk 

There is a simpler way that I didn't see before:

#Remove n randomly selected elements from list L:
RemoveRand:= (L::list, n::nonnegint)-> combinat:-randcomb(L, nops(L)-n); 

And here's an example of its use:

#Construct a random list:
R:= rand(-99..99):
L9:= sort(['R()'$9]);

        L9 := [-83, -82, -73, -44, -10, -4, 62, 80, 97]

#Remove 3 randomly chosen elements from it:
L6:= RemoveRand(L9, 3);

               L6 := [-83, -44, -10, -4, 62, 80]

@Carl Love I just posted a complete solution to this problem in the Posts section. My solution was elaborate enough, generic enough, and didactic enough that it seemed to warrant being put in Posts.

@eggoodaire Let me know if you need help putting those commands together. Please post if you work it out on your own!

Your Question doesn't make much sense to me, because if a list is sorted, and you remove some elements, then the remaining elements are still sorted! And why would you eliminate 0 elements 19 times?

@torabi Yes, I easily achieved that plot. I thought that you'd not be happy with the singularity, so I just said that there were "convergence issues". Since the interval is much smaller than a single period of your voltage function, it seems strange to me.

@primogen The derivative wrt a function can be computed by Physics:-Fundiff:

Physics:-Fundiff~(SimplifiedMassMatrixDot, theta[1](t))

Why are you using [diff] instead of diff? Not that there's anything wrong with [diff], but I'm curious Why do you find the the extra brackets useful? 

@yonasmibi Thanks. Both your transcription of the formulas into your code and my interpretation of your transcription were correct. We were simply confused because in English the word "rabbit" begins with letter R, which is used instead for the foxes in your model.

I will post a corrected procedure shortly.

@primogen When you save a Maple worksheet, it pretty much only saves what is needed to display what's on your screen. It doesn't save anything that you've obscured with the output-suppressing colon. So, you usually can't send that worksheet to someone else and say "See, that command didn't work. Please diagnose what I'm doing wrong," unless it's something trivial that can be diagnosed just by looking at the input.

Check out Acer's worksheet also. He achieved a substantial simplification of your Matrix using commands combine and simplify

@tomleslie It must be that R is the foxes and K is the rabbits. The letters might come from another language. The equilibrium is K = a/b,  R = c/b/e. With the given parameter values, that's 200 and 15.

@primogen How can you know whether the command worked or not without looking at its output? Your most-recent worksheet indicates that you didn't look in the Matrix dMM_t, and I see no error message.

@JackLe Acer has shown the use of the official transpose operator: (...)^%T , which can be used with official Matrices and Vectors. It can also be (...)^+. 

@primogen I'm surprised, but maybe it's a version difference. It worked in my Maple 2018. I see that you're using Maple 2017. Try

dMM_t:= diff~(MM_t, t);

Putting a tilde ~ after any operator makes it elementwise, but many commands are automatically elementwise, such as, apparently Maple 2018's diff.

If that doesn't work, post the executed worksheet showing the contents of MassMatrix.

What you call "assignments" above are actually just equations, although I see that you tried to use the assignment operator := in your worksheet. That's not allowed. Just use =. They won't be used automatically. You can apply specific simplifications with the simplify command at the point where they're needed. But let's deal with that later, after the diff is fixed. Just the generic simplify would probably handle this case anyway.

Could you post the recurrence equations and the initial conditions? I think that you either switched the roles of K and R somewhere or that you switched a plus/minus sign somewhere. I say this because after I corrected your program above, I still can't get convergence to an equilibrium (other than [0,0]) for any initial conditions that I try.