Some definition of n! where n are the negative integers is taken to be infinity. (this is Gamma function for negative integers).

https://en.wikipedia.org/wiki/Gamma_function

So 1/(-1)!  should be zero. And that is what Mathematica gives

But Maple does not like (-1)!, it gives division by zero, I assume because it is not using the above definition using Gamma function.  But then how come Maple is able to find correctly this sum

sum(1/factorial(n-1),n=0..infinity)

Which is exp(1).   The first term above, when n=0 is   1/(-1)!  which Maple does not like. Because if we take the first term as 1/infinity=0 then the sum is the same as if we had

sum(1/factorial(n-1),n=1..infinity)

And now it is exp(1) with no problem dealing with negative integer factorial.

Question is: Since Maple does not like negative integer factorial, how comes it accepted the above sum, whose first term contain negative integer factorial? 

Just wondering how it did the above, that is all. When I solved this by hand, I used 1/(-1)! = 0 to be able to sum it.

Hello pdsolve experts:  

Using Maple 2018.2.1 and Physics 292 on windows 10.

pde := diff(w(x,y),x)+ (arccot(x)^n *y^2 + y-  arccot(x)^n )*diff(w(x,y),y) = 0;
pdsolve(pde,w(x,y));

When I try

PDEtools:-charstrip(pde,w(x,y))

It does not generate error.

Should pdsolve have generated this error message instead of returning no solution?

Maple currently can't integrate things like sin(x)^n or cos(x)^n. These have antiderivative in terms of  hypergeometric functions.

Is there a technical reason why Maple at version 18 still can't integrate these? Will it be able to in next version?

int(cos(x)^k, x) 
int(sin(x)^k, x) 

fyi, These are the antiderivatives

Same problem for tan(x)^n....  I am asking because Maple is able to solve many ODE's but some results contains unevaluated integrals such as the above. 

When making this call to dsolve

restart;
ode:=diff(y(x),x)=1:
stopat(dsolve);
dsolve(ode,y(x));

Then in the debugger, I see that dsolve signature is

dsolve := proc(ODEs::{anything} := NULL, 
                {atomizenames::truefalse := true, build::truefalse := false, type::name := 'none'})

When typing print(ODEs) inside the debugger, it gives "diff(y(x),x)=1" which is correct.

But where is the second argument I passed to dsolve in the above call, which is "y(x)" gone?  I also do print(_nparams) inside the debugger and Maple returns 1 and not 2.

I expected to see 2 since I passed in two arguments to dsolve.

dsolve actually works without passing y(x), as follows

dsolve(ode);

And it seems Maple figure inside what is the dependent variable.

But my question is, is the second argument being thrown away before calling dsolve? If not, why it does not show in the debugger?   Is there some other pre-processing being done between the time the user calls dsolve() and the time the debugger is called?

I found a case where pdetest fails when called after another call to pdetest. I am using Physics version 272 from the clould. Using Maple 2018.2.1 on windows 10

restart;
u:='u';x:='x';t:='t';
pde := diff(u(x, t), t) + diff(u(x, t),x) =0;
sol:=pdsolve(pde,u(x,t));
pdetest(sol,pde);
    #0  OK
   
#restart;
u:='u';x:='x';t:='t';
pde:=diff(u(x,t),t)+diff(u(x,t),x)=0;
bc:=u(0,t)=0;
ic:=u(x,0)=sin(x);
sol:=pdsolve([pde,ic,bc],u(x,t)) assuming x>0;
pdetest(sol,pde);
   
     #sol := u(x, t) = -sin(-x+t)*Heaviside(-t+x)   #OK
     
     #-Dirac(-t+x)*sin(x)*cos(t)+Dirac(-t+x)*cos(x)*sin(t)+
      Dirac(-x+t)*sin(x)*cos(t)-Dirac(-x+t)*cos(x)*sin(t)   #WRONG should be 0
 

If I run the above again, but with restart call in between active, so that all is cleared, then pdetest gives 0 as expected on the second pde, with the same solution

restart;
u:='u';x:='x';t:='t';
pde := diff(u(x, t), t) + diff(u(x, t),x) =0;
sol:=pdsolve(pde,u(x,t));
pdetest(sol,pde);
   #0   #OK
   
restart;
u:='u';x:='x';t:='t';
pde:=diff(u(x,t),t)+diff(u(x,t),x)=0;
bc:=u(0,t)=0;
ic:=u(x,0)=sin(x);
sol:=pdsolve([pde,ic,bc],u(x,t)) assuming x>0;
pdetest(sol,pde);
   
   #0   #OK !! 

can any one explain why this happens?  Is this a bug? It seems like pdetest caching problem. it remembers something from the last call and this affects the result it gives for the next call.

any work around?