Wolfram Alpha has the potential to react
like this, since its not only input -> program,
but rather input -> (?timely?) knowledgebase.
At least it looks like that from the
outside sometimes. So it all depends
what this should really mean:
"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." - RJF
Am Mittwoch, 7. März 2018 20:33:25 UTC+1 schrieb burs...@gmail.com:
> 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)
|
