MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

RE: Re: Maintaining a Mathematica bug list

  • To: mathgroup at
  • Subject: [mg97559] RE: [mg97524] Re: Maintaining a Mathematica bug list
  • From: "David Park" <djmpark at>
  • Date: Sun, 15 Mar 2009 05:28:26 -0500 (EST)
  • References: <14874019.1237075110231.JavaMail.root@m02>

I think this is the case of the perfect being the enemy of the useful. It is
not so important that every single bug be in a maintained bug list for
users. It is more important that major new bugs that affect a large number
of users be on a list. I could see a useful bug list being less than a few
dozen items. If some relatively savvy Mathematica user wanted to maintain
such a list they might publish it on MathGroup once a week, say. They might
pick up the bugs from MathGroup, or once they became known, users might send
bugs to them directly. But if it is something obscure and difficult to
verify the list maintainer shouldn't be expected to spend a lot of time
checking it, or put it on the list. Sometimes he might just say that
so-and-so reported trouble with such-and-such a function. Sometimes WRI
might even send him bugs, or comment or correct the list.

A short list of high impact bugs would be useful. A long exhaustive list
with deep analysis and verification would be too much work.

David Park
djmpark at  


From: Bill Rowe [mailto:readnews at] 

On 3/14/09 at 5:34 AM, szhorvat at (Szabolcs Horv=C3=A1t) wrote:

>Presently the only way to learn about bugs is to follow MathGroup
>closely, but even when I remember that I've seen a bug (that might
>be relevant to me at the moment) mentioned a couple of months ago, I
>cannot always find the posts that described it.

Given Wolfram doesn't post bugs to Mathgroup, it is clear there
has to be another way to learn of bugs which is to experience
them yourself. The advantage of a bug list is that it (ideally)
provides a means to check whether some unexpected result you get
is a bug or not. But, without Wolfram's involvement I doubt this
ideal will be achieved with a third party bug list.

There are several issues. First, what criteria will be used to
determine a given result is a bug? A new user might see
Mathematica's failure to simplify Sqrt[x^2] to x as a bug.
Mathgroup is full of posts from less experienced users labeling
results as "bugs" more experience users know are expected and
are not bugs.

Assume for the moment all entries on the hypothetical bug list
are truly bugs. How will the list be organized and the bugs
cataloged? Given many functions in Mathematica are
interdependent, a single bug could impact more than one
function. Would there be a separate entry for each function
affected by the bug? And for a reported bug that is validated,
without the source code, how can anyone know if the bug is
limited to just the specific function reported? Similarly,
without the source code, how could you determine two separate
reports for differing functions are really separate
manifestations of the same bug?

My guess is without Wolfram's involvement, the bug list will
rapidly become a list of unexpected results rather than a true
bug list. As a consequence, this bug list will become no more
useful than Mathgroup with respect to finding information on bugs.

  • Prev by Date: Re: Re: Re: The "Go Back" Button doesn't work
  • Next by Date: Re: Weird NMinimize behaviour
  • Previous by thread: Re: Maintaining a Mathematica bug list
  • Next by thread: Re: Maintaining a Mathematica bug list