On Sun, 27 Jan 2008 20:01:35 +0100, Christopher Creutzig
<christopher@[EMAIL PROTECTED]
> wrote:
>Vladimir Bondarenko wrote:
>> On Jan 26, 12:50 pm, Christopher Creutzig <christop...@[EMAIL PROTECTED]
>
>> writes:
>>
>> http://groups.google.com/group/sci.math.symbolic/msg/b1d22cd149c93198
>>
>> CC> I agree that in a more perfect world, we'd have at
>> CC> least such consistency checks for all the things CAS
>> CC> systems are doing. But for many things, that is
>> CC> simply not doable.
>>
>> This is completely false.
>
> Wrong. It is absolutely true. Please learn some fundamentals, such as
>the basic problems about determining whether a constant expression is
>zero. This is *undecidable* (in the strong, well-defined sense of that
>word used in computer science) for a Turing machine, with the only
>constraint being that the algorithm terminate in finite time.
>
>> If designed and implemented with care, it can help, and
>> without hurting the CAS performance badly.
>
> Sorry, but I know you hardly know anything about implementing computer
>algebra. There's nothing wrong with that, of course, and quite a few of
>the bugs you've published are valuable starting points for QA work. But
>please stop writing nonsense about things in which you've obviously
>never gained experience.
I think _you_ miss the point.
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.
Microsoft learned this lesson the hard way with buffer overruns.
It's a lesson that keeps on getting relearned by each generation of
developers.
Professional programs, designed for public use, need to check their
inputs at every stage. No internal routine should "trust" the calling
routine unless the input arrives with a "certificate of validity", and
an indication of whether exact (if symbolic) or, if approximate, a
bound on the error. Similarly, outputs should be accompanied by such a
certificate, freeing the next routine from the obligation to check its
inputs (except to inspect the certificate), but not freeing it from
the obligation to certify its output.
The performance loss in return for guaranteed reliability is worth it
for many applications, as long as the penalty is not too severe. For
most routines, the performance penalty should be negligible, since
checking is typically faster than solving, but in the worst case, I
would not expect a certified system to take more than twice the normal
time.
Moreover the CAS can offer 2 modes -- a "draft mode" (like for a
printer) which gives fast results but with no guarantees, and a
"certified mode" which guarantees the final output to within a
specified error tolerance.
Is it doable? Of course!
Is it easy? Well, it may require a full redesign of the internals --
not a small task, so no, it's not so easy, but it doesn't require
rocket science -- just a careful redesign.
The CAS providers who undertake such a redesign will have that as a
huge selling point in their favor. One can judge the relative quality
of a CAS based on its range of im****tant features, its ease of use,
its speed, _and_ its reliability. Let the best CAS win!
quasi
|
