Re: Wolfram Research QA process defect: Bug in Mathematica 6 - Integrate - 68 (Sqrt, invalid value) - BUG THE LONG LIVER: 1996-2008 (!)

Daniel Lichtblau wrote:
On Jan 28, 12:34 pm, Jeff Barnett <jbb...@xxxxxxxxx> wrote:
Daniel Lichtblau wrote:
On Jan 28, 2:42 am, Vladimir Bondarenko <v...@xxxxxxxxxxxxxxx> wrote:
I don't quite understand the intent of the above remark: Is it to imply
that VB is responsible for determining why there is a glitch; i.e., is
he responsible for debugging someone else's code? If so, could you tell
me what you believe in general is the responsibility of consumers and
other victims?

The intent is to note that endless repetition of what appear to be
identical underlying bugs, with modestly differing inputs, is not of
use in helping anyone except possibly the one posting the endless
reports.

I will comment on your use of the term "victims". This is an
unmoderated forum, and you are of course welcome to use whatever
language you choose. That noted, I will also point out that I know
many of the people involved in implementation of symbolic computation
programs (commercial and otherwise). I very much doubt you will be
taken seriously by any of them if you resort to such terminology when
discussing the coding and usage of technology that is still very much
a work in progress.


I believe the better way for this to go down is the following: The
vendor, after discovering a bug, announces to all current and potential
customer that there is a bug and its impact so the consumers can act
intelligently by avoiding the problem and not re-reporting the same bug.

Announces that there is a bug in definite integration? More accurate
would be to note that some types of symbolic definite integration are
fraught with problems, both in algorithmic limitations and in code
technology. These are things I have remarked on a few times in this
forum, and elsewhere.

At times I think it is almost more noteworthy to announce when
symbolic definite elliptic integrals work correctly. But that level of
cynicism comes of seeing the various ways in which such things can
break.


For the most part, the vendors implicated by VB don't do their part.

How would one know that?


One of the CAS rarely discussed here - MATLAB - is used to design
algorithms and generate code, from the math, that actually flies in
aircraft.

Matlab, while it might be a useful and well engineered program, is not
a computer algebra system in any sense of which I am aware. It most
certainly does not do symbolic definite integrals involving elliptics,
or convolution methods with MeijerG functions.


For those of you that think CAS bugs are natural, expected,
and okay (and other people too), I recommend hard hats in case a steel
and titanium bug manifestation drops out of the sky near you. We could
also talk about hospital systems that are more and more automated and
depend more and more on math things (image processing, etc.) and decide
whether the current CAS are ready to contribute.

-- Jeff Barnett

The current programs that do symbolic computation are also used in
various industrial design capacities. I really doubt they are being
used fo their symbolic elliptic integration capabilities, in such
instances. Certainly Matlab is not being used in that way.

Above and beyond that, you really should strive for serious discussion
rather than this "sky is falling" stuff (if you want to be taken
seriously, at least by serious people). Yes, bugs in programs can and
do contribute to engineering fiascos and occasional outright
tragedies. More commonly, sound use of state of the art program
technologies, symbolic computation methods sometimes among them, lead
in useful directions in terms of research, design, and development.

The fact that symbolic computation is not, at this time, one of the
major players in leading new technological development might just
indicate it is still a young field. Or that the algorithms are not
(yet) sufficiently developed. Or maybe that it is not terribly
relevant. I really doubt it in any way reflects excessive corporate
greed, or a cavalier attitude amongst commercial and free software
developers, in terms of R&D or QA processes. Which is what I see being
implied and/or stated explicitly, in this recent spate of posts about
symbolic calculus.


Daniel Lichtblau
Wolfram Research
Daniel,

You seem to be worried whether I, as opposed to my opinions, will be taken seriously by developers, etc. Let's address that issue so we can get back to a more appropriate academic debate about CAS and the current state of the art vis a vis what might be better. My credentials for "being taken seriously" include: 1) supporting the development of REDUCE in the early days, 2) kibitzing (half a dozen visits a year to MIT) the development of what is now called Macsyma, 3) inventing and implementing JAM (Jeff's - I'm Jeff - Algebraic Manipulator) used to design and developed many of the Apollo control systems, 4) invitee and attendee at the first every SIGSAM meeting in Washington DC, 5) acknowledged contributions in Clark Weisman's Lisp Primer - coding examples throughout the book were the development of a little CAS, 6) participant and leader in Lisp 2 program that embedded chunks of ScratchPad and Flip as part of the basic language system, 7) etc.

My guess is that the developer(s) of Macsyma, Reduce, ScratchPad, and JAM would all be horrified (as well as amused?) at the amount of errors in the current crop of systems. Just a guess: the vast increase in computer speed has been so seductive that developers have raced ahead of their ability to properly code and check out that code. That's the charitable view. The alternative viewpoint is that commercialism is too seductive.

As To Matlab: It sure is a CAS whether it specifically does elliptic, or any other particular type of manipulation. It can take an s-plane diagram/description of a system and generate control algorithms that are flyable. In some senses, doing this well enough to achieve FAA approval is a much harder problem that Wolfram or other similar vendors are tackling. In other senses, it isn't. However, producing flight-worthy software from mathematical input is quite an achievement. It's one of the major accomplishments of your industry so don't knock it.

As to "announcing a bug in definite integration." That's hopeless. If definite integration doesn't work in general, that product version should be delayed and not shipped. The announcements I have in mind should be MUCH more specific so a reasonably knowledgeable user (not necessarily a world beater) knows which parts of the system are suspicious. Such announcements are, of course, the responsibility of the vendors. If you believe otherwise, then ask your masters to distribute the source code. (Didn't think you would.)

As to "the sky is falling." I spent many years trying to convince some large engineering concerns that their future would be well served by using CAS, particularly those enhanced with serious domain knowledge (such as Matlab) and auto-code capabilities, to design and build complex artifacts. Most of the response I got was expressed disdain at the state of the art and maintenance of the necessary tools.

Lastly, I think it is inappropriate for you to ask VB to determine whether two errors that he discovers are from the same source or different sources. As I assume you know, two expressions that look very similar may be handled by radically different code inside the CAS, e.g., replacing a "*" by a "/" might change an integration from "elementary" to not and the CAS will follow different paths.

-- Jeff Barnett
.