From: fateman@cs.berkeley.edu   
      
   The original comment from Axel did not have the full context of the   
   question, which was posted to a Maple newsgroup.   
      
   For the readers of sci.math.symbolic, here are 3 expressions,   
   in Maxima syntax, that are the source of the Maple complaint..   
      
   [F,G,H] :   
      
   [(%e^(-%i*n*t-%i*(1-n)*t)*(%e^%e^(%i*t)+1))/(((%e^%e^(%i*t)-1)/(   
   e^(2*%e^(%i*t))+1)+1)*cosh(%e^(%i*t))),   
      
   (%e^%e^(%i*t)+%e^(-%e^(%i*t)))/(2*cosh(%e^(%i*t))),   
      
   (%e^(-%i*t)*(-2*cosh(%e^(%i*t))+%e^%e^(%i*t)+%e^(-%e^(%i*t))))/cosh(%e^(%i*t))]   
      
   in Maxima,   
   F,exponentialize, ratsimp    returns 2*exp(%i*t)   
   G,exponentialize             returns 1   
   H,exponentialize             returns 0   
      
   So apparently the solution is similar to the one in Maple,   
   to convert to exponentials.   
      
   Why does Wolfram Alpha seem to do better?   
   Or more particularly, Why does Wolfram Alpha do better on these examples?   
      
   I think the answer is this: Mathematica has a program   
   (FullSimplify)  that thrashes madly trying to simplify stuff,   
   and sometimes succeeds. Mostly when the input is small.   
   When the input is complicated and there is no really great   
   "simple" form that emerges from trying this, that, and the   
   other thing, it just goes on for a long time. Maybe a very   
   long time.  It may be stopped eventually by some time-limit   
   setting.   
      
   Maple, Maxima, Axiom  etc.  may not have this flailing simplifier   
   (though frankly, I don't know about Maple or Axiom on this score...).   
      
   So why does Alpha work?   In these cases it finds a winner   
   in the early flailing, before it runs out of time.  Will Alpha   
   always work?  Certainly not. Indeed, Provably not. It has   
   been proved that the task of testing whether some f(t) is   
   identically zero is recursively undecidable (D. Richardson, c. 1967)   
   and so no algorithm can be devised that will always work.   
      
   So given these constraints, what should a CAS designer do?   
      
   Axel seems to think it is absurd that a CAS simplifier   
   cannot solve these problems by some regularization or   
   standardization.  Yes, in these cases, but just what regularization?   
   And if you were to apply something like FullSimplify at   
   each possible occasion, would your program be too slow?   
      
   consider...  until f=0  do f:  hairyfunction(f)   vs.   
                 until FullSimplify(f)=0 do ..   
      
   either one might be the right choice, but if you insert   
   the FullSimplify()  without any user action, you are   
   placing a dangerous choice out of reach of the user, who   
   may desperately want results faster, and who may know   
   that hairyfunction(f)  will be a huge mess but eventually   
   be exactly 0.   
      
   So people COULD write a FullSimplify() in these other systems,   
   but just as is the case for Mathematica, it would be   
   foolish to use it all the time.   
   (A challenge:  write such a program.  You'll need some metric   
   for comparing 2 expressions to see which is "simpler", and maybe   
   some hill-climbing heuristics.)   
      
      
   For Alpha, it might make sense to use it because humans typing   
   stuff typically give small inputs, and Alpha will throw you off   
   after some short period of time, regardless.   
      
   RJF   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)