Maybe CAS should become AI, and we should send   
   CAS programs to libraries, so they can read that   
   fermats last problem was solved, and can return "no".   
      
   Am Mittwoch, 7. März 2018 20:20:01 UTC+1 schrieb Richard Fateman:   
   > 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)