@tomleslie 

The big problem is that the OP has copied the 2D math as text and has pasted here.
(In my opinion the 2D math is more difficult to be used correctly for a beginner than the old 1D; it should not be the default!).

BTW, in 2D,  f(x) := ...   is converted into an arrow procedure definition f := x -> ...  Of course f(x+1) := ... is superfluous and represents an useless entry in the remember table.

@dharr 

Yes, it's strange. It seems that when the point is infinity, taylor calls `series/infinity` and does not check the polynomiality of the result.
IIRC, in the past taylor was a regular procedure but now it is builtin and it's not posible to see its code.
Pi versus pi is not relevant here:  taylor(x^(1/x), x=infinity);

Actually we can obtain a little more general result:

If P is a polynomial in x with deg(P,x) = 2*n  then it has a unique representation
         P = a*Q^2 + R, 
where a is constant, Q, R are polynomials, Q is monic, deg(Q,x) =n, deg(R,x) <= n-1.

The procedure CompleteSquare rejects the representation if R is not constant.

SQR1:=proc(P::polynom(anything,x), x::name)
local n:=degree(P,x)/2, q,r,Q,R,a;
if not(type(n,posint)) then error "degree(P) must be even" fi;
a:=lcoeff(P,x);
Q:=add(q[k]*x^k,k=0..n-1) + x^n;
R:=add(r[k]*x^k,k=0..n-1);  #q,r ==> 2*n unknowns
solve({coeffs(expand(P-a*Q^2-R),x)}, {seq(q[k],k=0..n-1),seq(r[k],k=0..n-1)});
a*eval(Q,%)^2+eval(R,%)
end:

SQR1(2*x^6-8*x^4-5*x^3-9*x^2-4*x-8,x);
SQR1( a*x^2+b*x+c, x );
SQR1(54*x^6-216*x^5-72*x^4+684*x^3+168*x^2-288*x+51, x);
               

@Vitreg2 

The taylor command does not (and cannot) return such things.
Please post your worksheet (use the green arrow on the toolbar).

@Kitonum 

Yes, but e.g. if you want to plot3d it, you must use first expand  etc.

@Magma 

Inside the iteration you can do anything with v which contains the list [i1,i2,...]. In CartesianProduct the only difference is that v is an Array.

f := (i, r) -> add(i[j]*r[j], j=1..nops(r));

Q:=proc(k::list(nonnegint), r::list)
local P,i,v;
P := combinat:-cartprod([seq([seq(0..i)],i=k)]);
while not P[finished] do 
  v :=  P[nextvalue]();
  print( f(v,r) ); 
end do;
end:

Q([2,3],[r1,r2]);
                               0
                               r2
                              2 r2
                              3 r2
                               r1
                            r1 + r2
                           r1 + 2 r2
                           r1 + 3 r2
                              2 r1
                           2 r1 + r2
                          2 r1 + 2 r2
                          2 r1 + 3 r2

@Joe Riel 
This works:

r2_r1 := r -> rhs(Optimization:-Maximize(eval(Ept,r1=r), r2=1000..1700)[2][]):
plot(r2_r1, 1000..1700);

Nice post!

What happens for r=r1 > 1680 in r2vsr1? Why this instability? What could be the interpretation for the value 1680?

@nm 

The problem is that sol is not a classic solution and Maple is not fully prepared to work with distributions such as Dirac.
(When using Dirac, the user is supposed to know what operations are allowed from a mathematical point of view).
In my opinion in such situations pdsolve returns a "formal" solution. It is the user who decides whether it suits his needs and in what sense the solution is to be interpreted (e.g. distributional). That's why pdetest cannot fully verify it.

BTW. The equation is very simple and the solution is simple too. Are you satisfied with it? Forget that it was found by Maple, do you accept it?

@Carl Love 

I was curious about the timings and I was a bit surprised that the seq version was about 10% faster.

@minhthien2016 

It was of course noted. As mentioned, all the listed solutions have the in-sphere centered at [0,0,0], So from the first solution ==> the tetrahedrons  {[-20+a, -3+b, -3+c], [-20+a, 3+b, 3+c], [20+a, -3+b, 3+c], [20+a, 3+b, -3+c]}
having the in-sphere at [a,b,c] in Z^3.

(Without the second condition the problem would be trivial.)

@ecterrab 

So, the help file says:

The eval option to subs also performs a full evaluation while keeping the semantics the same as for subs. This option should be used with care.

But your answer contains:
subs[eval] ... evaluate only the subexpressions where a substitution happened.

This explains the difference in my question. I think that the help file should contain this statement.
Now everything is clear. Thank you.

@ecterrab 

Thank you, the fix was really quick.
I still wonder about the difference between eval(subs(...)) and subs[eval](...) in my question.
Now, unlike value, the commands are builtin and unfortunalely the help page only mentions that the latter "should be used with care".

Happy New Year!

@Rouben Rostamian  

I think the behavior is intentional because it appears in an example (and in many help pages some essential information is found only in examples).
It is probably acceptable in the cases when the functions have always the same arguments. But othewise the results could be strange:

PDEtools[declare]();
diff(p(s,t),s) + diff(p(s,v),s) + diff(p(u,s),s);
     p[s] + p[s] + p[s]
lprint(%);
      diff(p(s,t),s) + diff(p(s,v),s) + diff(p(u,s),s);

@Christopher2222 

A default for an absolute width cannot exist because it should make visible the arrows for both vectors <0.5, 0.5>  and  <999, 999>.