Using Stephen Wolfram's "new kind of science," we can simply define the derivative with respect to a forced integer argument to be 0, always. Thus, modifying your command slightly, we get

evalf(eval(diff(n*Zeta(n, 3), n), {n= 3, diff= 0})); 
      -0.3740436824

which is what you expected. I'd guess that this is the way that Mathematica views it.

A more-formal implementation of this idea could be made by making a small adjustment to `diff/Zeta`, which is only a 9-line procedure. Specifically, the unevaluated 'diff' in lines 4 and 7 could be replaced by 0. So, a one-line patch is

restart:
`diff/Zeta`:= subs(''diff''= 0, eval(`diff/Zeta`)):

#Now, redo your original command:
evalf(eval(diff(n*Zeta(n, 3), n), n= 3));
      -0.3740436824

Your procedure can be simplified to 

#construction d'un carré connaissant 2 sommets opposés 
car_2som_opp:= proc(U::list, V::list)  
local 
   X:= [add(V)+`-`(U[]), add(U)-`-`(V[])]/2, 
   Y:= [add(U)+`-`(V[]), add(V)-`-`(U[])]/2
;
   plot([U, X, V, Y, U], scaling= constrained, axes= none) 
end proc:

So, there's no need for solve, square roots, or distance formulas.

Using the modern Statistics package and other innovations, your computation can be done like this

restart:
N:= 400:
list_of_k:= [40, 20, 10, 5, 2, 1]:
st1:= Statistics:-Sample(EmpiricalDistribution([-1,1]), N):
st:= (evalf@table)(
   [seq(k= [seq(add(st1[i*k-k+1..k*i]), i= 1..N/k)]/~sqrt(k), k= list_of_k)]
);

Your two questions, the first about the end-of-parameters marker and the second about LCState, are completely unrelated. But I'll try to answer both.

If the end-of-parameters marker is the only "parameter" of a procedure, then the procedure cannot be passed any arguments; in other words, its only valid argument sequence is NULL or (); or, in more other words, the number of arguments must be 0.

The end-of-parameters marker "works" by making the name ` $` a parameter of the procedure. You can see that via 

P:= proc($) end proc:
lprint(op(1, eval(P)));  #op(1, ...) of any procedure is its parameter sequence.
` $`

Almost anything enclosed in backquotes is a symbol (which is a kind of name) and a valid procedure parameter. If that's not enough information for you, please try asking a more-specific question. I don't have access to the kernel source code, but a great deal can be deduced about it from black-box experimentation.

Regarding LCState: It's not a command; it's just an integer-valued local variable in module RandomTools:-LinearCongruence. Local variables are usually not publically documented, and we unfortunately don't have access to comments in the original code. However, I know enough to tell you exactly what it is. 

First, the following two commands help you to poke around inside modules:

• interface(verboseproc= 2):
  This prevents the internal contents of system procedures and modules from being printed as "...".
• kernelopts(opaquemodules= false):
  This lets you treat module locals as if they were exports, giving you both read and write access. This is a very powerful debugging tool.

Read the help page ?RandomTools,LinearCongruence. There you'll see that each random integer is generated by applying a trivial linear modular arithmetic computation to the previous random integer. To do this, that previous random integer must be stored somewhere. Indeed, it's stored in LCState. That's all that LCState is. In most discussions of random number generators, this state variable is called the "seed".

The following session confirms that what I said above is true:

interface(verboseproc= 2):  kernelopts(opaquemodules= false):
RCLC:= RandomTools:-LinearCongruence:
op(2, eval(RCLC));  #op(2, ...) of a module is its "header".
module ()
   local simpleLGInertProc, complexLGInertProc, Prime, Gen, Shift, LCState;
   export GenerateInteger, NewGenerator, GetState, SetState;
   option package, `Copyright (c) 2004 Waterloo Maple Inc. All rights reserved.`;
end module

op([2,2], eval(RCLC)); #Specifically op([2,2], ...) is its locals.
simpleLGInertProc, complexLGInertProc, Prime, Gen, Shift, LCState

RCLC:-LCState;
                               1
RCLC:-GenerateInteger();
                          427419669081
RCLC:-LCState;
                          427419669081
 

You had another Question about a month ago about another Markov chain with a tridiagonal transition matrix. That was very similar to the current matrix, although this chain has absorbing states (corresponding to the 1s on its diagonal) and that one did not. In my Answer to that Question, I showed you the easy way to enter a matrix that's organized by its diagonals (called a band matrix) using the scan= band option. You didn't use that here.

It looks like you want to compute the long-run probabilities for this Markov chain. In my previous Answer, I showed how to do that for a chain without absorbing states. The method to do that when there are absorbing states is different. The worksheet below repeats what you did, but with easier coding, and provides a general procedure for the long-run probabilities of an absorbing Markov chain.
 

Download AbsorbingMarkov.mw

.

Your code works for me in Maple 2019. But its working depends on x and y (lowercase) being unassigned. To fix that, you should add x, y, and i to the local list.

Also, display does nothing is this case and isn't needed. Just remove display. The purpose of display is combining multiple plots or changing the options on an existing plot. Since you're not doing either of those things, only the plot command is needed.

Here is another way. It's similar to Joe's, but I prefer the elegant syntax of mine. I also do the exact example that you gave, doing it both in D form and diff form.
 

Download DifferentialMatrixCompositions.mw

If procedure f1 is passed into procedure f2, then it's often useful to exctract f1's parameters while in f2. That can be done with op(1, eval(f1)), which I use in my procedure DP below. That op command will return the parameters with their type specifications, if any were provided. These can be removed to obtain a list of just the names of the parameters like this:

(p-> `if`(p::`::`, lhs(p), p))~([op(1, eval(F))])

I recommend that you not try to use an Array as the input parameter to a procedure formed from a symbolic algebraic expression, such as you do with Ff. So, I'd make Ff

Ff:= (x,y)-> (sin(x)+20)^2 + (cos(y)+5)^2;

Then my DP returns the gradient as a procedure:

DP:= proc(F::procedure, N::posint:= infinity)
local P:= (p-> `if`(p::`::`, lhs(p), p))~([op(1, eval(F))]), n:= min(nops(P), N);
   unapply(VectorCalculus:-Vector(n, k-> D[k](F)(P[..n][])), P[..n])
end proc:

So that you can use it to get a symbolic gradient:

DP(Ff)(x,y)

or an evaluated gradient:

DP(Ff)(Pi/3, Pi/4)

So, the usage of DP is very much like D.

The second (optional) parameter of DP is an integer n that specifies that only the first n parameters of F are to be treated as independent variables in the sense of calculus; if n is omitted, then all are used, which should cover the vast majority of cases.

If you really need Ff to take its parameters in an Array, let me know why, and I'll come up with a solution.

This graph seems generic enough that it's worth generalizing to any size. Thus:

Truss:= proc(n::And(posint, even))
uses GT= GraphTheory;
local
   k, p, 
   B:= k-> seq(k+~p, p= ({-1,0}, {-1,1}, {0,1}, {0,2})),
   T:= GT:-Graph({seq(B(k), k= 2..n-2, 2), n-~{1,0}})
; 
   GT:-SetVertexPositions(T, [seq([[k,1],[k,0]][], k= 1..n/2)]); 
   T
end proc
:   

GraphTheory:-DrawGraph(Truss(8));

Your C program is a top-level 'main' program which interacts directly with the user and doesn't explicitly return any nontrivial value. You need to change that to a function which takes arguments (specifically, at least one Matrix argument) and returns a value (a Matrix) and does NOT interact with the user^[*1]. See the help page ?external_calling. The example mat_mult given on that page is very close to what you need.

[*1] Possibly there is some way that I'm not aware of that the external program can interact with the user while running in Maple, but this would be some unusual and advanced case.

Any rtable (which includes Vectors, Matrices, and Arrays) V can be converted to a sequence simply with seq(V). I think that you're having some confusion about the distinction between sequences and lists (which is, admittedly, a minor and idiosyncratic distinction). If I say

S:= 1, 2, 3;

then S is a sequence with three entries. If I say 

L:= [1, 2, 3];

or

L:= [S];

then L is a list with three entries. The most-important difference (and it may be the only significant difference) between a sequence and a list is that a sequence cannot ordinarily be passed as a single argument to a single procedure parameter (there are a few tricks to get around even this).

So, your n__a is a sequence of Vectors. It can be converted to a list of lists by

[seq]~([n__a]);

As Tom Leslie has pointed out, there is no way to specify the order of set elements. They are stored in a specific (and predictable) order that is convenient for Maple. Thus, it seems that sets aren't at all suitable for your purpose, so I won't discuss them further in this Answer.

Anything that you can do to narrow the search space will help fsolve (this does not apply to solve). In this case, a little bit of plotting should convince you that there is a negative solution. Simply providing that information to fsolve is enough:

params:= {
    k = 1.3806e-23,
    T = 300,
    h__bar = 1.05456e-34,
    L__z = 6e-9,
    m__hhw = 3.862216e-31,
    E__hh0 = 3.012136e-21,
    E__hh1 = 1.185628e-20
}:
p:= k*T*m__hhw*(ln(1+exp(E__fv-E__hh0)/(k*T))+
  ln(1+exp(E__fv-E__hh1)/(k*T)))/(Pi*h__bar^2*L__z) = 0.3e25;

fsolve(eval(p, params), E__fv= -infinity..0);
                          -48.46001884
 

@mehdi jafari There are two completely separate issues involved in the cases that you show where simplify(...) assuming real doesn't return what you think it should. In the first case, you use

simplify(..., sqrt) assuming real

In this case it's the sqrt that's preventing the simplication that you want, and this would still be true even if the the input were a single algebraic expression rather than a Matrix. Instead, change your command to

simplify(...) assuming real

I don't consider the above to be a bug, or even a weakness.

In your second case, you use

simplify(S_NEW(2,2)) assuming real

where S_NEW is a Matrix. Here, you are using the so-called programmer indexing, i.e., you put the indices (2,2) in parentheses rather than square brackets, [2,2]. This case does seem to be a weakness of assuming (it's not a weakness of simplify); however, I recommend that you always index with square brackets unless you specifically know that programmer indexing is required for your operation (such a situation is rare). So, if you change the above to

simplify(S_NEW[2,2]) assuming real

then it'll work.

The command that you're thinking of is IterativeMaps:-Bifurcation. See its help page. However, I am confused by your usage of an equation rather than an expression.

When a worksheet (or document) is viewed as a slideshow (via menu View => Slideshow), its sections become the slides. This means that you need to make each section small enough that it fits on one screen. So, if you need to present a slideshow, it'd be wise to first perfect your edit of the flat (un-sectioned) worksheet, then divide it into sections. Also, the presentation is fixed slides rather than executable code. Generally, when I give a presentation, I prefer to execute key parts of the code directly for my audience. That helps maintain their attention.

This seems to me to be a very weak feature of Maple.