List of real bugs in built-in functions (was Re: Re: "At long last, Sir, have you no shame?")
- To: mathgroup at smc.vnet.net
- Subject: [mg18440] List of real bugs in built-in functions (was Re: [mg18385] Re: "At long last, Sir, have you no shame?")
- From: mkraus <mkraus at immd9.informatik.uni-erlangen.de>
- Date: Wed, 7 Jul 1999 00:11:27 -0400
- Sender: owner-wri-mathgroup at wolfram.com
David Withoff wrote:
> Martin Kraus wrote:
>
> > Hmmm, I guess we could quickly gather dozens of well known
> > bugs in this thread. Before doing so: Is there anyone who
> > would like to set up a database with online access for
> > bugs (including workarounds) in Mathematica?
>
> One response to your request for someone who would like to set up
> such a database is that Wolfram Research is interested in this, and
> is already doing it. The "support section" of the Wolfram Research
> web site is a "database with online access for bugs (including
> workarounds) in Mathematica".
Hmm, are you talking about the "Technical FAQ"?
I would not consider most of the problems described there as
bugs. And the mentioned problems which are bugs seem to have
been patched already.
> Another response is that a few individuals have volunteered
> independently to make bug lists in the past; perhaps if you find
OK; thus, I should search the archive of MathGroup for addresses.
Thanks for the hint.
> such a person you could ask them about their experiences. Typically
> the first problem encountered is the observation that independent
> experts often disagree about what is or is not a bug. To avoid
What about this definition: As soon as a programmer of WRI says
that a problem is not a bug (i.e. it SHOULD NOT be corrected
in Mathematica) the problem is not a bug and the discussion about
it belongs to a FAQ or MathGroup.
> getting bogged down in irresolvable arguments, the scope of the task
> is then expanded to include any behavior that anyone might conceivably
> report as a bug, so the list includes things like why (-1)^(1/3)
> isn't -1, various consequences of numerical error, expected limitations
> of various algorithms, and so forth. This greatly expands the task.
Sure. When I suggested a "database with online access" I did NOT
think of a couple of HTML pages! A "database with online access"
should include a possibility for all visitors to send their
problem (like a the student support forum). Certainly there should
be someone who removes problems which are solved or which are not
bugs. (A second list might keep the patched bugs with links to the
patches.) Workarounds for unsolved bugs belong to the list with unsolve
bugs (IMHO a patch is not a workaround but the solution for a bug).
> The next problem is how to organize this material so that people
> can find things in the list. It is useful if the list has some
If we are talking about bugs in the sense that WRI does not deny
that a built-in function has to be corrected, then the bug should
be accessible via the (full) name of the built-in function (or
operator).
What about bugs in the front end, which are not connected with
any Mathematica function? Well, at least I am not so much interested
in them; much more important are bugs in the kernel and built-in
functions. These platform-independent bugs are the real problems
when trying to do calculations with Mathematica. Thus I should
more precisely talk about a list of bugs in the kernel, the
built-in functions and the standard packages.
> sort of structure, with keyword searches so that, for example,
> someone who reports the behavior of (-1)^(1/3) as a bug can find
> the appropriate item, and so forth. Then there is the problem of
> dealing with the more common case where it is not the behavior of
> (-1)^(1/3) that gets reported, but rather an example such as
>
> In[1]:= Solve[x^(1/3) + 1 == 0, x]
>
> Out[1]= {}
>
> reported as a bug in Solve (because it doesn't report x -> -1 as a
> solution), even though this is just an alternate manifestation of the
> behavior of (-1)^(1/3), and neither behavior is actually a bug.
That's right. It is not a bug. Therefore, it belongs into a
FAQ list. Not into a bug list. I think we agree about this point.
> When faced with these and other problems I'm pretty sure that everyone
> other than Wolfram Research who has tried to prepare a bug list has
> essentially given up, leaving the technical support section of the
> Wolfram Research web site as the best current bug list.
I disagree. The technical FAQ includes patched bugs but not a list of the
unsolved bugs. However, it is probably the best current bug list published
in the web.
> Yes, there
> is always more work to be done, there are items that haven't yet been
> written up,
I disagree. Every software company should have a list of bugs of their
products and I am quite sure that WRI has a rather long list of bugs.
It is not in the web and there might be reasons for this policy.
> there are organizational improvements that haven't yet been
> added, etc., but the technical support section of the Wolfram Research
> web site is still a pretty good bug list.
For patched bugs: Yes. For uncorrected bugs: No.
> Most of the bugs that get
> reported to Wolfram Research Technical Support are described there, and
Are you sure? I am surprised. Well, you are probably right in the sense
that most of the technical questions reported to WRI support are answered
there. That's a different point.
> even a lot of things that aren't bugs are described there (there are
> several notes about the behavior of (-1)^(1/3), for example).
>
> Dave Withoff
> Wolfram Research
In fact the Technical FAQ is very well done and I am not critizising
the support at WRI. My idea is to set up a list of real bugs and this
does probably not belong to the support section at WRI but to the
developers. The primary purpose of such a bug list is to warn users
about bugs which are well known and have not been patched yet. In some
cases there might even be a workaround available (using other functions
for instance). Another purpose is to inform the developers (not the
support) about bugs and--even more important--that they cause trouble.
IMHO there are still good reasons for a list of real bugs in the kernel,
the built-in functions and the standard packages apart from the technical
FAQ with little or no overlap.
Greetings
Martin Kraus