Re: Bug in Mathematica 6 - Integrate - 63 (Sqrt, regression bug)
- From: Daniel Lichtblau <danl@xxxxxxxxxxx>
- Date: Sun, 27 Jan 2008 07:25:08 -0800 (PST)
On Jan 27, 1:05 am, Vladimir Bondarenko <v...@xxxxxxxxxxxxxxx> wrote:
On Jan 26, 12:50 pm, Christopher Creutzig <christop...@xxxxxxxxxxx>
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.
If designed and implemented with care, it can help, and
without hurting the CAS performance badly.
You are talking (writing) based on no experience. Implement a symbolic
calculus program, say, and then you'll have some basis to judge such
matters. For one, you'll have a much more clear idea as to whether
they might help in any significant way.
Implementing an "autocheck" for various types of computation makes
good sense, within a software testing environment. Using it inside the
actual computations is generally a RBA ("real bad idea"). There are
exceptions, e.g. using numeric checks to discard parasite roots in
algebraic system solutions. But that tends to be a fairly well defined
area.
It is an open question of whether and when to use such checks
automatically in symbolic integration. Unlike algebraic solvers, there
are myriad problems lurking. I'll name a few.
(1) The symbolic integral might contain functions that are slow to
numerically evaluate accurately.
(2) The checks involve quadrature. This can be significantly slower
than the symbolic integration, particularly as dimension increases.
(3) Quadrature can be prone to errors.
(4) These only are applicable when no parameters are present, or
numerical values within assumption and proviso ranges (if any) have
been selected for the parameters.
None of these impede the use of such checks in the QA process. They
simply mean that such a check is difficult to make within the symbolic
integration itself.
I am scared to hear such a viewpoint from a SciFace GmbH
person responsible for QA process.
There's no doubt that such a viepoint is at least in part
responsible for at least many thousands distinct defects
in MuPAD 4.
Not knowing specifics of MuPad development, I'd be inclined to suspect
there are several distortions in this statement.
(1) I've seen ample reference to a document claiming another program,
Maple, has "dozens thousands distinct bugs" in some version, possibly
aple 9.5. Said document is partly correct in that it shows clear sign
of the "dozens" distinct bugs. But the "thousands" part was suspect
(okay, conspicuously absent), and really was ly repetition of the same
underlying defects as were categorized in the "dozens".
Point being, from past history I'd be inclined to believe the part
above about MuPad having "many" distinct defects. But I'd not take
seriously the "thousands" claim without independent corroboration.
(2) The claim originally was that exact integration is not likely to
use a numeric check. This reluctance can contribute to some level of
bugginess but I rather doubt it contributes to much, given the
impediments to implementing it well.
(3) It may well be the case that SciFace GmbH uses such methods in
their QA testing processes. The original remark, again, was simply
that it is not readily used in symbolic computations themselves.
Case in point: Integrate in Mathematica does not at this time use
quadrature checks via NIntegrate. But they are used, and in some
places automated, in the testing of Integrate. My opinion is if we
tried to add such quadrature checks to Integrate itself, we'd break
more than we fixed.
(4) Those who write, maintain, and (at least for the commercial ones)
market computational math programs need to have a sense of where to
place finite resources. It is quite possible that the MuPad developers
simply disagree with your implied claim that symbolic calculus is a
high priority area.
You may wish to consider some comments here.
[...]
A question to the SciFace GmbH leaders/owners
from the #1 world CAS QA engineer
Self-proclaimed. Always remember that. You are the "self-proclaimed #1
world CAS QA engineer." That sort of thing makes a difference, in the
world of credentials (consider the overall level of regard for the
various self-proclaimed mathematics geniuses who post to Usenet).
[...]
Best wishes,
Vladimir Bondarenko
[...]
On Jan 26, 12:50 pm, Christopher Creutzig <christop...@xxxxxxxxxxx>
wrote:
[...]
--
if all this stuff was simple, we'd
probably be doing something else. -- Daniel Lichtblau, s.m.symbolic- Hide quoted text -
[He sounds like a sensible sort. I hope to be like that some day.]
Daniel Lichtblau
Wolfram Research
.
- References:
- Re: Bug in Mathematica 6 - Integrate - 63 (Sqrt, regression bug)
- From: Christopher Creutzig
- Re: Bug in Mathematica 6 - Integrate - 63 (Sqrt, regression bug)
- Prev by Date: Re: Bug in Mathematica 6 - Integrate - 63 (Sqrt, regression bug)
- Next by Date: Re: Wolfram Research QA process defect: Bug in Mathematica 6 - Integrate - 64 (Log, Cos, false convergence, multiple regression bug)
- Previous by thread: Re: Bug in Mathematica 6 - Integrate - 63 (Sqrt, regression bug)
- Next by thread: Re: Bug in Mathematica 6 - Integrate - 63 (Sqrt, regression bug)
- Index(es):