The following two versions both handle Pi without resorting to evalf.

f := proc(x) if is(x < 0) then x^2+1 else cos(x) end if end proc:
#Alternatively:
f:=x-> if is(x < 0) then x^2+1 else cos(x) end if;

f:=proc(x) piecewise(x < 0, x^2+1, cos(x)) end proc:
#Alternatively:
f:=x->piecewise(x < 0, x^2+1, cos(x));

The empty question deserves the empty answer.

Without seeing the procedure it is not possible to give the reason for the delayed evaluation.

The behavior, however, can be mimicked by the the following procedure, which just forces delay:

p:=proc() local cndtn1,cndtn2,bv1Lappr,bv1Rappr,Mi,bv1L,bv1R;
cndtn1 := -19882.77350*exp(0.9901951500e-2*bv1L)+2.172519170*exp(-1.009901952*bv1L)+200.*bv1L+19880. = -19882.77350*exp(0.9901951500e-2*bv1R)+2.172519170*exp(-1.009901952*bv1R)+200.*bv1R+19880.;
cndtn2 := -2.007965147*10^6*exp(0.9901951500e-2*bv1L)-2.151217913*exp(-1.009901952*bv1L)+2.008*10^6+100.*(bv1L-.6)^2+20000.*bv1L = -2.007965147*10^6*exp(0.9901951500e-2*bv1R)-2.151217913*exp(-1.009901952*bv1R)+2.00800015*10^6+100.*(bv1R-.6)^2+20000.*bv1R-(-19882.77350*exp(0.9901951500e-2*bv1R)+2.172519170*exp(-1.009901952*bv1R)+200.*bv1R+19880.)*(bv1R-bv1L);
bv1Lappr := -1.428147401;
Mi := -.712642354728244;
bv1Rappr := .6644399282;
#The delay is forced by using unevaluation quotes: ' ' around fsolve.
'fsolve'({cndtn1, cndtn2}, {bv1L, bv1R}, {bv1L = bv1Lappr .. Mi, bv1R = Mi .. bv1Rappr});
end proc:

#The two results from your post are reproduced with the following two commands:

p();

%;

Thanks to hirnyk for typing the numbers from your images. Bringing code in the form of images would make most people give up answering. It is much better to be able to copy and paste, as you can with my code above.

You could do like this, where you notice the use of the elementwise operations =~, <=~, op~, and convert~. Elementwise operations were introduced in Maple 13.

z := <yb,x1b,x2b>:
v1 := <v1y,v1x1,v1x2>:
v2 := <v2y,v2x1,v2x2>:
e1 := z =~ v1 + v2;
e2 := v1 <=~ UU*delta1;
e3 := v2 <=~ UU*delta2;

S:=op~(convert~({e1,e2,e3},set));
V:=op~(convert~({v1,v2},set));
solve(S,V);

In the case of equations I have been using the following extensions of convert for a while. They also work in earlier versions of Maple.

`convert/listeqs`:=proc(L::equation({Vector,Matrix}))
ListTools:-Flatten(convert(zip(`=`,lhs(L),rhs(L)),listlist))
end proc:
`convert/seteqs`:=proc(L::equation({Vector,Matrix})) convert(zip(`=`,lhs(L),rhs(L)),set) end proc:

The subprocedure handling Heaviside in ztrans is `ztrans/zrule`['Heaviside'].

And that one checks if No has type 'integer'. Since No (with or without assumptions) is not an integer, ztrans returns unevaluated.

(You mistyped the type check :: , but since it doesn't have an effect, it doesn't matter).

If the procedure is changed to something like the following, it seems to work:

`ztrans/zrule`['Heaviside']:=proc(f,stepexp,n,z) option `Copyright (c) 1995 by Waterloo Maple Inc. All rights reserved.`;
local i,s,r;
if type(stepexp,'linear'(n)) then
  s:=coeff(stepexp,n,1);
  r:=-coeff(stepexp,n,0)/s;
  if type(r,integer) or hasassumptions(r) then if is(0<=r) then `ztrans/ZT`(f,n,z) - (sum(subs(n=i,f)/z^i,i=0..r - 1)) else `ztrans/ZT`(f,n,z) end if
else '`ztrans/ZT`'(Heaviside(stepexp)*f,n,z) end if
else
  '`ztrans/ZT`'(Heaviside(stepexp)*f,n,z)
end if
end proc;

The changes are in this part:

if type(r,integer) or hasassumptions(r) then if is(0<=r) ......

c:=table():
a:=[5,6,7]:
b:=[4,3,9]:
counter1:=1:
counter2:=1:
for i in a do
  for j in b do
    c[counter1,counter2]:=i+j:
    counter2:=counter2+1
  end do:
counter2:=1; 
counter1:=counter1+1
end do:

eval(c);


It is rather curious, indeed. And disturbing!

Apparently by saving the module in the second example mp:-mult evaluates to the global variable mult, which has not been defined to be anything.

If inside the procedure f2, mult is replaced by mp:-mult, then both versions work, also after saving.

However, if you create a Maple archive and save your packages there, both seem to work fine:

restart;
#mkdir("F:/temp");
march(create,"F:/temp/mp.mla",10);
restart;
mp1:= module()
export mult, f2; option package;
mult:=proc(v) 3*v end proc;
f2 :=proc(v) mult(v); end proc;
end module;
savelibname:="F:/temp/mp.mla";
savelib(mp1);
restart;
libname := libname, "F:/temp";

with(mp1);
f2(5);
mult(4);

restart;
mp2:= module() export f2, mult; option package;
mult:=proc(v) 3*v end proc;
f2 :=proc(v) mult(v) end proc;
end module;

savelibname:="F:/temp/mp.mla";
savelib(mp2);

restart;
libname := "F:/temp",libname;

with(mp2);
f2(5);
mult(4);

The time spent in converting a given nice and simple answer into something else is (I find) usually rather frustrating, and maybe not worth the effort.

I did the following, but notice in particular the simplify(..., symbolic) and the convert(...., arccosh):

res:=simplify(int(9/sqrt(81*x^2-4),x));
convert(res,arccosh);
simplify(%,symbolic);
res2:=radnormal(%,rationalized) ;
plot([res,res2],x=2/9..10);

The answer is in terms of arccosh, but not in the form you wished.

If you change the Export to pdf format setting to "Export using shapes for greater fidelity" then the export to pdf seems to work fine (I used the letters you provided above).

(Tools/Options/Export)polishTEST3.pdf

Here is another idea.

The procedure _RemoveMyAssignments unassigns all user assigned names, but because of the leading underscore, it doesn't unassign the name _RemoveMyAssignments.

If the procedure is placed in a library, it won't be unassigned either. See the help for 'anames'.

_RemoveMyAssignments:=proc() local L;
L:=map(convert,[anames('user')],string);
unassign(op(map(parse,L)))
end proc:

p:=plot(sin);
tr1:=87;
t[6]:=14;
M:=Matrix(3,3,(i,j)->i+j);
_RemoveMyAssignments();
p,tr1,t[6],M;
eval(t);
eval(_RemoveMyAssignments);

The responses from select and remove ought not be unexpected.

In the help page it says:

"The select function selects the operands of the expression e which satisfy the Boolean-valued procedure f, and creates a new object of the same type as e. Those operands for which f does not return true are discarded in the newly created object."

(emphasis added).

The type of ccc (i.e. sin(x)) is function (which in Maple means unevaluated calll to a function). The function in question is obtained by doing
op(0, ccc);

i.e. it is the 0'th operand. For a list this would be 'list'. For a sum it would be `+`, etc. 

The operands of f(x,y,z) are x, y, z (numbered 1, 2, 3).

So

op(sin(x));

just returns x.

select(has, sin(x), x);

will select among the operands those for which has(...., x) is true, in this case the argument x. After that an object of the same type as the original is returned, thus the result is sin(x).

remove(has, sin(x), x);

will act accordingly. There will be no argument left, so the result will be sin(), however if you evaluate that further (by merely doing %;) you get an error message because sin does not accept no arguments.

If your list is a list of lists you can do as follows using scan:

restart;
A:=[[1,2,3],[4,5,6]];

Matrix(A);

#Same as:

Matrix(A,scan=[rectangular,rows]);

#But now different:
Matrix(A,scan=[rectangular,columns]);

You can change Fortran order to C order as follows, but it doesn't affect the dimensions:

restart;
A:=[1,2,3,4,5,6];
M:=Matrix(3,2,A);
MC:=Matrix(M,order=C_order);
lprint(MC);

The same happens in Maple 14, but as suggested in the help page you can change Normalizer from the default normal to e.g. radnormal:

Normalizer:=radnormal;
IsSimilar(A,A,output=['C']):
simplify(%);

After attempting PDEtools[dcoeffs], it seems that actually this works also on a pde, not just an ode (the equation eq2 is defined below):

dd:=convert(indets(eq2,specfunc(anything,diff)) union {f(x,y)},list):

coeffs(eq2,dd,'terms');
               1 + r + y, 5 + 4 y + z, 1, 3 + 4 x
terms;
          d            d  / d  / d         \\   d  / d         \
f(x, y), --- f(x, y), --- |--- |--- f(x, y)||, --- |--- f(x, y)|
          dx           dx \ dx \ dx        //   dy \ dx        /

Notice that as described in the help page for coeffs there is a 1-1 correspondence between the output from coeffs and the contents of 'terms'.

If your input is a polynomial in the indeterminate and its derivatives then you can use dcoeffs from the PDEtools package:

eq1:=simplify(( (3+4*x)*diff(f(x), `$`(x, 2)))+(5+4*y+z)*(diff(f(x), x))+(1+r+y)*f(x)):
PDEtools[dcoeffs](eq1,f(x));
                3 + 4 x, 5 + 4 y + z, 1 + r + y

#The help page describes ODE's and although at first it seems to work on a pde:

eq2:=simplify(diff(f(x,y),x,x,x)+(3+4*x)*diff(f(x,y), x,y)+(5+4*y+z)*diff(f(x,y), x)+(1+r+y)*f(x,y)):
PDEtools[dcoeffs](eq2,f(x,y));
               3 + 4 x, 1, 5 + 4 y + z, 1 + r + y

#You notice that the order of the coefficients is surprising.

Using collect w.r.t. diff could be useful:

collect(eq1,diff,factor);

collect(eq2,diff,factor);

The simplest:

diff(f(a*y),y);

#Defining a new function g as g(y) = f(a*y):

g:=unapply(f(a*y),y);
D(g);
D(g)(r);

# Using dchange from the PDEtools package is relevant in a more complicated context, e.g. if you like to nondimensionalize a differential equation:

restart;
eq:=diff(f(x),x)=b*f(x)^2+c*f(x);
PDEtools:-dchange({f(x)=q*g(y),x=a*y},eq,[y,g]);