Take the logarithm of the function and the contour levels. This causes no change in the shape of the plot. It only rescales the colors.

plots:-contourplot(
     ln(exp(2*x/(x^2+y^2))), x= -2..2, y= -2..2, grid= [100$2],
     coloring= [blue, red], contours= ln~([.1, .3, .5, 1, 2]), filledregions
);

All that you need is

D(p)(v);

I'd be amazed if there weren't an easy one-line way to do it in Mathematica also.

This is an annoying, but documented, feature of assuming. Specifically, assuming doesn't work on variables that only appear inside functions. It is mentioned on the help pages ?assuming and ?assuming,details. Since it seems to have been designed that way, perhaps there are situations where this behavior is desirable. I can't think of any right now. To work around:

A:= mmFun(t);
simplify(A) assuming g__1::positive;

This works because g__1 appears at the top level in expression A rather than inside a function.

In your "this works sometimes" addendum, the map is insignificant. It works because the resultMatrix contains the already-evaluated function call.

z:= x+I*y:
plots:-intersectplot(
     abs(z^2/2+3*z-1), 1, x= 0..1, y= -0.5..0.5,
     axes= frame, orientation= [270,0]
);

An empty matrix can be created with simply Matrix(), or, if you want to be more explicit, Matrix(0).

Your construction, [][], is equivalent to NULL, which is a valid expression sequence but not a Matrix. Nonetheless, your procedure does work exactly as you wrote it. Why do you say that it doesn't work? Perhaps your function_coeffs is wrong. 

Your procedure can be simplified to

Initial_Matrix:= proc(BC::list, n, BP::list)
local bc;
     <seq(function_coeffs(bc, n, BP), bc= BC)>
end proc;

You don't need a loop to define indexed procedures. A procedure can "see" the index with which it's called by using op(procname). Do this:

u:= t-> L/2*cos(w*t);
v:= t-> H*sin(w*t+phi[op(procname)])

Braces can't be used as an "outer level" of parentheses. Only parentheses can be used for algebraic grouping. Braces have a highly specialized meaning: enclosing the elements of a set. I'm not aware of any practical computer language that allows anything other than plain round parentheses for algebraic grouping, although such usage is standard in mathematical writing.

Unfortunately, I can't find a help page that says this. However, I'm absolutely sure that it's true for Maple's Maple Input (aka 1D input). 

According to the Fundamental Theorem of Linear Algebra, the null space of a matrix is the orthogonal complement of the row space. So, use command LinearAlgebra:-NullSpace, like this:

A:=<4,1,0,0; 0,0,4,1>:
A1:= <A, `<|>`(LinearAlgebra:-NullSpace(A)[])^+>;

Now A1 will be the matrix that you want, with the new rows added at the bottom.

You need to distinguish between equations (made with the equals sign =) and assignment statements (made with the := operator). What you want in this case are equations. Use seq instead of for for the looping:

Eqs:= [seq(
     u[i, j] = (u[i-1, j] + u[i+1, j] + lambda*(u[i, j-1]+u[i, j+1]) +
                 sigma(h, r[i+1])*(u[i+1, j]-u[i-1, j]))/mu,
     i= 1..6
)];

An equation is an object which can later be solved or otherwise manipulated. An assignment is a command---an action---which has no existence after it is performed.

Both in math and in Maple, matrix indices start at 1. However, if you want to start at 0, you can use an Array, which is very much like a Matrix:

N:= 3:
K:= Array((0..N)$2, (i,j)-> D[1$i,2$j](k)(0,0)/i!/j!);

N needs to be defined before the Array, but k does not.

One advantage of a Matrix is that it'll show up on screen as a matrix, in the ordinary fashion, if it's sufficiently small. We can shift the indices to make this a Matrix:

N:= 9:
k:= (x,y)-> exp(x)*sin(y):
K:= Matrix((N+1)$2, (i,j)-> D[1$(i-1),2$(j-1)](k)(0,0)/(i-1)!/(j-1)!);

Use sprintf, not cat, to convert Maple expressions to strings:

r:= sprintf("dsolve(%q,y(x))", eq);

Or use fprintf to send the string directly to a file.

If you use the %q format, then the strings will always be rereadable as Maple code.

fun_coeff:= proc(p::algebraic, ux::function(name), n::nonnegint)
local P:= convert(p, :-D), u:= op(0,ux), x:= op(ux), k;
     [seq(coeff(P, (D@@k)(u)(x)), k= 0..n)]
end proc:    

fun_coeff(P, u(x), 4);

Use the arrow operator -> to define functions. By combining this with `if`, the definition can be specialized to the first argument being 0.5:

g:= (x,y)-> `if`(x=0.5, 200*y, 'procname'(args)):

y:= 4:
g(0.5, 4);

     800

g(x,y);

     g(x, 4)

You simply need the elementwise operator ~:

EQ=~0;

If you end your intermediary commands with a semicolon rather than a colon, you'll be able to track down the error more easily. Upon doing this, I quickly see that at least one of the intermediary results, the one that you called s[2], contains the value Float(infinity). This indicates some invalid operation, akin to dividing by 0, was attempted.

Regarding the use of colon or semicolon inside loops: All that matters is which is after the end do (or equivalent) of the whole loop. So you might as well use semicolons for the statements inside loops because it's easier to type.

You can't treat a variable (aka a symbol or a name), such as s, and its indexed subscripted forms, such as s[2], as if they were separate and independent variables. This can cause trouble if you assign to the subscripted form and then attempt to use the unsubscripted form as a free variable (which is exactly what you do here), and it'll definitely cause trouble if you assign to both of them. I'm not sure if this is the source of all or any of your trouble, but it must be corrected before we can move forward.

This caution about subscripted names only applies to indexed subscripted names, i.e., those formed with square brackets. If you form the subscript by using double underscore __ or double vertical bar || or a combination of those, then you can treat the resulting names as separate and independent variables.