MathGroup Archive 2002

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

Search the Archive

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


  • Prev by Date: Re: RE: Trace a function
  • Next by Date: RE: Colors
  • Previous by thread: Re: Functionality and Reliability
  • Next by thread: Re: Re: Functionality and Reliability