Re: Maintaining a Mathematica bug list
- To: mathgroup at smc.vnet.net
- Subject: [mg97579] Re: Maintaining a Mathematica bug list
- From: "Dr. David Kirkby" <david.kirkby at onetel.net>
- Date: Mon, 16 Mar 2009 04:23:03 -0500 (EST)
- References: <14874019.1237075110231.JavaMail.root@m02> <email@example.com>
David Park wrote:
> 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.
However, these high impact bugs are likely to be well publicised
already. A Google search will probably find many of these. College
lecturers are likely to know of them. I would expect them to be on the
WRI support pages too.
> A long exhaustive list
> with deep analysis and verification would be too much work.
It's clear that any attempt to thoroughly analyse a long list of obscure
bugs would need a lot of time dedicated by experts, and nobody other
than WRI are going to be able to do that. I think it is equally obvious
that WRI are not likely to make such a list public.
However, there would in my opinion be a use for a collection of
'reported/unverified bugs'. User 'A' just lists what they thinks is a
bug, and user 'B' can believe or disbelieve as they see fit. User 'C'
could add a comment like "this is a usage error, you should use Sin[x]
not sin(x)" or similar. With a bit of luck, someone from WRI might
comment, but it could not be expected.
I've stuck a few Solaris-specific Mathematica bugs I've come across over
the years at
Ignoring the first few, which are only telling you what is already in
the documentation, I believe 5 of those:
1) Mathematica 5.x using excessive CPU time on Solaris 10.
2) Mathematica uses excessive CPU time on multi-processor machines
3) Mathematica 6.0.1 or 6.0.2 has some characters unreadable
4) Mathematica fails to determine the number of CPUs correctly on SPARC
5) Mathematica crashes on Solaris x86 with an Intel CPU
are listed with sufficient detail to enable someone to decide if they
believe them or not. The 3rd of these affects Linux too, the 5th is not
a bug, but a workaround of how to get Mathematica working on a Solaris
x86 system with an Intel CPU, rather than the supported AMD CPU. (I find
it amazing Wolfram support AMD CPUs but not Intel, especially as I have
made them aware how to solve the Intel issue).
In my opinion, bug reports in that form are useful. The problem is that
to make best use, they would need being in a searchable database. This
would probably be software like Bugzilla with a mySQL backend.
I think it is fair to say a typical Mathematica user is likely to be of
above average intelligence, so hopefully would be able to write a bug
report in a reasonably useful manner.
You also need to consider that students working on college licenses
don't (officially at least) have direct access to WRI support, but need
to go via a university contact. Home use licenses in the US will have
limited technical support (no option for premier service). A searchable
public list might be particularly useful to that group.
If anyone did set up a decent bug database, they would need to consider
security and spam issues.
* You can be sure someone is going to post an attachment which is a PHP
script which attempts to hack your web server.
* Someone might post spam.
* Someone will try to upload a root-kit (or whatever the Windows
* A hacker will attempt to exploit security issues in the bug database
software (Bugzilla or similar). So effort would be needed to keep that
up to date.
* Someone will attempt to exploit bugs in web server software (Apache etc)
* Someone will attempt to upload porn.
* Someone will attempt to upload viruses.
I think setting up the database and subsequent security maintenance
would be the time-consuming things - not verifying the bugs, which I
believe would be impractical and unnecessary.
One final issue, WRI might object to a public bug list. I personally
don't feel they should, but they might do, claiming it is hurting their
product to have reports of bugs that are not bugs, but user errors. They
could threaten legal action if someone did not take it down. I *very*
doubt that would happen, as I suspect it would do them more harm than
good and give their competitors something to shout about, but it just
possibly could happen.
Prev by Date:
Re: Reading in an ASCII file written by a FORTRAN program
Next by Date:
setting discrete values for a function -- newbie
Previous by thread:
RE: Re: Maintaining a Mathematica bug list
Next by thread:
How to get data from Histogram