quasi wrote:
> I think _you_ miss the point.
Maybe. I know I did a few times in the past, but that's part of what a
discussion is all about.
> No one is saying that a CAS can always give valid outputs, given valid
> inputs.
>
> Rather the CAS code should _defend_ against inputs which are out of
> range for the given algorithm. If the input is out of range, the CAS
> should fail, returning an error message rather than a wrong answer.
Please re-read what I quoted and what I replied to. While there is some
value in cross-checking with semi-heuristic methods, such as numerical
evaluations often are, for automated testing (I'm sure every CAS
producer has been doing that for ages), I (and others) highly doubted
the value of such an approach for on-line checking of results produced
in a production environment behind the scenes. This part is certainly
something that could be discussed at length, but any such discussion, if
it tries to go beyond personal gut-feeling, must include at least
empirical studies. I don't currently see anyone doing these.
The other part of my reply was that there are numerous things in a CAS
which simply *cannot* be reliably checked in a strong sense. I've
pointed to some theoretical background on the reasons for that. Nothing
of this is new, it's been proven decades ago and, to be honest, should
be part of the general knowledge for sci.math.symbolic authors, if not
readers. (Oh, BTW, I'm not going to keep responding to such excessive
crosspostings.) I regard it as highly surprising that Vladimir seems to
be unaware of these problems. (I am not surprised to see that he starts
spreading fud on MuPAD again. That's just a predictable reaction to my
pointing out some of his errors.)
Please note that I'm not talking about inputs which are “out of range.”
Some of the cases where you run into these fundamental problems may be
considered “out of range” for the algorithm implemented, but certainly
not “out of range” for the problem specification. Neither do I wish to
say “software is buggy, but it must be.” What I was trying to say is
“sounded like a good idea the first time I heard it, but this particular
approach does not work as generally as you imply, and here's why: …”
> Microsoft learned this lesson the hard way with buffer overruns.
Sorry? What's special about Microsoft in terms of buffer overruns? Just
about every programmer using a susceptible language has been bitten by
those at least once. And probably every server-like program has at one
time or the other had to be fixed because such a bug caused security
problems. I'm not saying that is all right. I just try to keep a
realistic world-view, to improve things that can be.
--
if all this stuff was simple, we'd
probably be doing something else. -- Daniel Lichtblau, s.m.symbolic
|
