From: fateman@cs.berkeley.edu   
      
   On 3/7/2018 12:25 AM, Nasser M. Abbasi wrote:   
   >   
   > I am, as a CAS user, not being vague at all. I am simply using   
   > a CAS commands, provided by the CAS maker to use.   
   > Which is to do some computation under some assumptions.   
      
      
      
   OK, here is a simple set of CAS commands:   
      
   assume ([a,b,c,n], integers);   
   assume (n>2),   
      
   solve (a^n+b^n=c^n,  [a,b,c,n]);   
      
   nothing wrong with that?   
      
   It would have saved Andrew Wiles and others (back to Fermat)   
   a lot of time if they had just typed those commands, or something   
   equivalent, into a CAS.   
      
   Oh, but maybe those CAS had bugs?  Shame on them.   
      
      
      
   The language of mathematics,  even when the language is   
   paraphrased into a constrained one-dimensional string of characters,   
   is sufficient to express problems that are   
      
   ambiguous or nonsensical   
   paradoxical   
   computationally unsolvable.   
      
   CAS attach that language to a set of programs   
   that have been written to solve a subset of   
   mathematical questions.  That subset may be   
   enlarged from time to time if systems are   
   improved.   
      
   Asking a CAS to solve a problem for which it has   
   not been programmed is not difficult.  Just pick   
   a problem that does not fit in the programmed   
   algorithmic subset of the system. There is a   
   class of "CAS independent"   "bugs" that they   
   all get wrong.   
      
   It is difficult to define exactly what each CAS subset is,   
   but even if it were defined carefully, I doubt that   
   (especially beginning) users would pay attention to it.   
      
   Another approach would be to tightly constrain   
   the utterances that are possible in the user language.   
   This is a very useful tactic, used, for example,   
   in the designs of vending machines, bank ATMs,   
   or 10-key+operators  calculators.  Most (all?)   
   CAS designers have not followed this approach.   
      
   A simple example that has come to mind recently   
   is how to treat "infinity".   
      
   Just because you can utter and compute  limit(1/x^2,x,inf)  does   
   NOT mean "inf"  with all its mathematical baggage   
   is completely understood by a CAS.   
      
   What is inf+inf?   inf^2?  inf-inf?  exp(i*inf)? sin(inf)?....   
   For that matter, humans disagree on what some   
   such utterances mean.   
      
   So to return to my claim.  You can use a CAS to do what   
   they are programmed to do. Just because its input   
   language allows you to make some inquiry does   
   not mean the CAS can make sense of it and answer it.   
   If you want to get useful results from a CAS, you may need to   
   apply some thought.   
      
   By analogy with cars, just because a car has a speedometer   
   that goes up to 120 miles per hour (i.e. about 200 kmph) does not mean that   
   it can actually go that fast.  Or that it is a good idea to try.   
   And the car odometer might have 6 digits, indicating that it will last   
     999,999 miles (or km?).  but it might not.   
      
   RJF   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)