How about this,
t:= seq(i*Unit(s),i=100..2000,100);
acer

This is probably not near the most efficient way, but...
dice := proc(n::posint)
local i, N, p, new;
new := convert(n, string);
N := iquo(StringTools[Length](new) + 1, 3);
p := Array(1 .. N);
for i to N do
p[i] := parse(StringTools[Take](new, 3));
new := StringTools[Drop](new, 3)
end do;
convert(p, list);
end proc:
dice(632096185);
diceL := proc(l::list(posint))
local i, j, N, p, new, result;
result:=Array(1..nops(l));
for j from 1 to nops(l) do
new := convert(l[j], string);
N := iquo(StringTools[Length](new) + 1, 3);
p := Array(1 .. N);
for i to N do
p[i] := parse(StringTools[Take](new, 3));
new := StringTools[Drop](new, 3);
end do;
result[j]:=convert(p, list);
end do;
convert(result,list);
end proc:
diceL([632096185,123456789,214365879]);
acer

p1:=nextprime(10^200);
p2:=nextprime(p1);
evalf(p1*p2);
p1:=nextprime(10^399);
p2:=11:
evalf(p1*p2);
acer

There are probably much easier and slicker ways to do the elimination, but four of the equations were so simple that it could be done "by hand".
restart:
C := 2:
TY := .9:
Y := Vector(1 .. C, TY/C):
TM := 1:
DL := 5:
eq1 := X1 = (Y[1]+Z2)/TM:
eq2 := X2 = (Y[2]-Z2)/M2:
TX := X1+X2:
eq3 := M2 = (1-X1)*TM+X1/(1/TM+W1):
W0 := Y[1]/TM^2+Y[2]/M2^2:
EF := W0/(1-TX):
eq4 := W2 = EF+X1*min(W2, DL):
eq5 := W1 = (TX*EF-X2*W2)/X1:
eq6 := Z2 = Y[2]*max(0, W2-DL)/W2:
# Four of the equations are so simple that we can eliminate
# them by hand.
list0 := subs(eq2,[eq1,eq3,eq4,eq5,eq6]):
list1 := subs(eq3,list0):
list2 := subs(list1[5],[list1[1],list1[3],list1[4]]):
list3 := subs(list2[1],[list2[2],list2[3]]):
# Solve the remaining two equations in two variables.
sol1 := fsolve({op(list3)},{W1,W2});
# Now backsubstitute.
z2 := eval(eq6,[op(sol1)]):
x1 := eval(eq1,z2):
m2 := eval(eq3,[x1,op(sol1)]):
x2 := eval(eq2,[m2,z2]):
# Check the original equations, by substition.
eval([eq1,eq2,eq3,eq4,eq5,eq6],[z2,x1,m2,x2,op(sol1)]);
# Here's a solution.
z2,x1,m2,x2,op(sol1);
# Find another solution, avoiding the first solution.
# It helps fsolve to know a range, which may also tell
# it that the ranges are purely real.
sol2 := fsolve({op(list3)},{W1,W2},avoid={sol1},
W1=-1000..1000,W2=-1000..1000);
z2 := eval(eq6,[op(sol2)]):
x1 := eval(eq1,z2):
m2 := eval(eq3,[x1,op(sol2)]):
x2 := eval(eq2,[m2,z2]):
# Check the original equations, by substition.
eval([eq1,eq2,eq3,eq4,eq5,eq6],[z2,x1,m2,x2,op(sol2)]);
# Here's a second solution.
z2,x1,m2,x2,op(sol2);
The two solutions I saw were,
Z2 = -0., X1 = 0.4500000000, M2 = 0.6744105183, X2 = 0.6672493797, W1 = 2.617057514, W2 = -22.32043803
Z2 = 0.4462841010, X1 = 0.8962841010, M2 = 0.1052051185, X2 = 0.03532051532, W1 = 600.8482070, W2 = 605.5062301
Increasing Digits didn't radically alter the final answer, so the simplified two equations seem "stable".
acer

The statement that "..in the above command, ALL numerical computations are being done with only two significant digits," doesn't seem quite right.
> stopat(`evalf/sin`):
> a:=sin(Pi/8):
> evalf(a,2);
The above indicates to me that computation is done something like,
> xr := evalf(Pi/8,2):
> evalf(evalhf(sin(xr)),2);
That still produces .36, sure. But the sine computation is done in evalhf it seems. The input to sin is just .37, though, as you described.
Is this next true? If one extra guard digits had been used in approximating Pi/8 then the final result would be accurate to 2 places.
> restart:
> xr := evalf(Pi/8,3):
> evalf(evalhf(sin(xr)),2);
0.38
Is sin "atomic" enough to warrant guard digits for approximating the argument, assuming what I wrote above is true?
acer

Does it work if you use (only) single-forward slashes?
acer

Something like this?
with(LinearAlgebra):
U:=Matrix(2,2,symbol=u):
V:=Matrix(2,2,symbol=v):
complicated_expr:=Determinant(U)
*CharacteristicPolynomial(U,x)/CharacteristicPolynomial(V,x):
func:=unapply(complicated_expr,
convert(map(rhs,rtable_elems(U) union rtable_elems(V)),list)
);
acer

When you issue,
Optimization[NLPSolve](proc2(a,b,c), a=50E-9..100E-9,b=100E-9..150E-9,c=50..100)
the first argument proc2(a,b,c) gets evaluated right away. This is how Maple normally works. That is, the unassigned names a,b,c get passed to proc2 right away. And the result of that evaluated call is what actually gets used as the objective.
There are several ways to work with this. The simplest was might be to put unevaluation quotes on the proc2 argument. Eg,
Optimization[NLPSolve]('proc2'(a,b,c), a=50E-9..100E-9,b=100E-9..150E-9,c=50..100)
Other ways might be,
Optimization[NLPSolve](proc2, 50E-9..100E-9,100E-9..150E-9,50..100)
Optimization[NLPSolve]((a,b,c)->proc2(a,b,c), 50E-9..100E-9,100E-9..150E-9,50..100)
Or you might be able to edit proc2 so that when its arguments are not numeric it returns its own procname(args) unevaluated.
For a simpler illustrative example, look at these,
foo:=proc(a) if a > 1 then a else 0 end if; end proc:
plot(foo(a),a=0..2);
plot('foo'(a),a=0..2);
plot(a->foo(a),0..2);
plot(foo,0..2);
foo:=proc(a) if type(a,numeric) then if a > 1 then a else 0 end if; else 'procname'(args); end if; end proc:
plot(foo(a),a=0..2);
acer

If I understand the problem correctly then, for a given Matrix M and Vector v of variables, you want that,
M . v = v
So, a logical progression of equivalent statements might be,
M . v = IdentityMatrix(Dimension(v)) . v
M . v - IdentityMatrix(Dimension(v)) . v = 0
( M - IdentityMatrix(Dimension(v)) ) . v = 0
So, isn't this the same as saying that v must be in the Nullspace of ( M - IdentityMatrix(Dimension(v)) ) ?
That is,
with(LinearAlgebra):
Nullspace( M - IdentityMatrix(Dimension(v)) );
acer

What are the variables? You've given three equations.
Are the Greek letters supposed to be parameters, and {p,s,n} the variables?
And what are the ranges for the variables? If the variables are {p,s,n} then you don't want just the trivial solution {0,0,0}, right?
So, I'm guessing what you want here. But maybe this is close.
ds := theta*p*(1-exp(-n))-rho*s;
dp := xi*(1-exp(-s))*(lambda-p)-p;
dn := mu*lambda*p*(1-exp(-n))-omega*n;
Fs := proc(Lambda,Mu,Theta,Rho,Xi,Omega)
local result;
result:=fsolve(subs([mu=Mu,theta=Theta,rho=Rho,xi=Xi,lambda\
=Lambda,omega=Omega],{ds,dp,dn}),{s,p,n});
result := eval(s,result);
if type(result,numeric) then
return result;
else
return Float(undefined);
end if;
end proc;
Fs(1,1,1,1,-1,1);
plot('Fs'(L,1,1,1,-1,1),L=1..3);
The above should plot s, as a function of lambda in the range from 1 to 3, holding all the other Greek letter parameters at constant values.
If that's what you're after then editing it to plot p or n, or depend on another of the parameters, should be straightforward.
acer

This is like counting, in base 3.
Imagine that the symbol "3" stands for the digit 2, the symbol "2" for the digit 1, and the symbol "1" for the digit 0.
> convert([2,2,2,2,2,2,2,2,2],base,3,10);
[2, 8, 6, 9, 1]
Reading the base-10 digits above from right to left, that's 19682. Add 1 to that, on account of the number zero, and you get 19683.
This simple procedure might help illustrate this idea. It won't be nearly as fast as combinat[permute].
> makePAT := proc(i) local PAT, nPAT, j;
> PAT := convert(i,base,3);
> nPAT := nops(PAT);
> PAT:=[seq(1,j=1..9-nPAT),seq(1+PAT[nPAT+1-j],j=1..nPAT)];
> end proc;
> makePAT(0);
[1, 1, 1, 1, 1, 1, 1, 1, 1]
> makePAT(19682);
[3, 3, 3, 3, 3, 3, 3, 3, 3]
acer

In the command,
plot(vec1[floor(x)], x = 1 .. 2);
the argument vec1[floor(x)] is evaluated right away. The error you saw is the same as you'd get if you issued simply,
> vec1[floor(x)];
Error, bad index into Vector
One way in which you can delay this evaluation (until x takes some actual numeric value) is by having the first argument instead be a function of x. Here's an example.
N:=10:
vec1:=LinearAlgebra[RandomVector](N):
plot(x->vec1[floor(x)], 1 .. N);
I used N=10 and a nonzero Vector just to make it more interesting. Your original example would have N=2 and a zero Vector, naturally.
acer

In the .eps file that is produced, there'll likely be some lines that look like this,
% set page orientation (usage: portrait or landscape)
/portrait {/po true def} def
/landscape {/po false def} def
You could try switching the true and false above.
Or, you might look for the section that begins with,
%%BeginSetup
and in that section find a line that is simply,
portrait
You might try changing that to landscape instead. It may be that only one of those two changes is sufficient. I suppose that it might also be the case that it's already set to landscape.
Or there might be a setting in SW to orient the inserted .eps image. If there is, I'd expect it to use those same standard terms, "portrait" and "landscape".
acer

Does it work OK if your Matrix ls_m is created with datatype=float[8]?
If so, then it'd be a weakness that neither the help-page mentions that datatype restriction nor the solver internally copies the integer[1] data to float[8] datatype. At least one of those should be true.
acer

I may have misinterpreted what you meant by the formatting with the dots. There are several ways to go about it. Here are a few.
g := proc(n)
local f,F,i;
f := (t,n) -> n+1/t;
F := 1/x;
for i from n to 1 by -1 do
F := f(F,i);
od;
F;
end proc;
g(5);
G := proc(N,n)
if n=0 then
1/x
else
N-n+1+1/procname(N,n-1);
end if;
end proc;
G(5,5);
N:='N':
H := proc(n)
global N;
if not assigned(N) then
N:=n;
end if;
if n=0 then
1/x;
else
N-n+1+1/procname(n-1);
end if;
end proc;
H(5);
acer