Re: Re: Functionality and Reliability
- To: mathgroup at smc.vnet.net
- Subject: [mg35003] Re: [mg34983] Re: [mg34958] Functionality and Reliability
- From: David Withoff <withoff at wolfram.com>
- Date: Wed, 19 Jun 2002 05:52:37 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
Although there are many remarks in this thread which could benefit from some analysis, there is one set of related points that I have found particularly interesting, which basically have to do with various tradeoffs -- between marketing and development, between fixing bugs and adding new features, and so forth. For example: > the time > spent on fixing or improving existing capabilities my be in direct > competition with developing new ones. It seems pretty clear from the > marketing point of view developing new features is a better policy than > fixing old ones. Much as I might like to blame my problems on marketing, this tradeoff is almost never an issue, primarily because fixing bugs and adding new features are almost never distinct tasks. An example that came up recently in this newsgroup was the observation that Series does not have a Direction option, and hence cannot control expansions around branch cuts, a fact which is reflected both in Limit and in Integrate. The only practical way to fix the corresponding class of bugs in Integrate is to add a feature (directional series expansions) to Series, which in turn requires adding a variety of lower-level features that bear no obvious relation to the bugs in Integrate, despite the fact that one of the primary motivations for adding those features is to fix bugs. The only involvement from marketing is in deciding how to describe these efforts. It sounds a lot more positive, for example, to emphasize the features that have been added rather than to say "we have completed 5 of the 15 tasks needed to fix an important class of bugs". If the features that have been added end up being independently useful, so much the better. All of this leads quite naturally to a collection of nominally sensible suggestions for dealing with the incompleteness of available algorithms: > I think it would > be much better if Mathematica had the ability to recognize the > unreliability of some of its answers in case they are the result of the > lack of sufficient general methods rather than simply bugs (Mathematica > does it sometimes, but only in a very limited way). While all of this is true, it seems important to add that the reason Mathematica does this only in a very limited way is that detecting that an answer is unreliable is almost always equivalent to making the answer reliable. If I had a procedure that could accurately detect the need for a directional series expansion, for example, I am all but certain that it would then be a simple matter to go ahead and do the directional series expansion. Finally, whenever I get to thinking about problems with Mathematica I find it helpful to remind myself that the overwhelming majority of results from Mathematica are entirely correct, and that by far the most common explanation for problematic results lies not with marketing or testing or anything else but rather with the perfectly honorable and inescapable fact that there are lots of things about mathematics and about computer algorithms that have yet to be discovered. Certainly there are exceptions to this, some of which I too find rather annoying, but a closer look at these annoyances almost always reveals a good explanation. Dave Withoff Wolfram Research