Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2002
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2002

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

Search the Archive

Re: Re: Functionality and Reliability

  • To: mathgroup at smc.vnet.net
  • Subject: [mg35010] Re: [mg34983] Re: [mg34958] Functionality and Reliability
  • From: Andrzej Kozlowski <andrzej at tuins.ac.jp>
  • Date: Wed, 19 Jun 2002 05:52:47 -0400 (EDT)
  • Sender: owner-wri-mathgroup at wolfram.com

On Wednesday, June 19, 2002, at 02:35  AM, David Withoff wrote:

> 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.
>

Of course I agree with all of the above, but it does not cover 
everything that can be said. I think there are also fairly clear cases 
involving usually some rather old parts of Mathematica that  would 
benefit from an overhaul, and I was trying to find reasonable 
explanation why this has not yet been done. One obvious candidate that 
comes to my mind is the Assumptions mechanism in Integrate. One can find 
many examples in postings on this list which show how unsatisfactory and 
erratic it is. Integrate will sometimes make arbitrary assumptions not 
requested by the user. On many other occasions it will ignore crucial 
assumptions entered by the user. But what I think most clearly 
illustrates the problems mentioned is the rather large number of 
integrals can be properly evaluated only using input of the form 
Integrate[Simplify[function,assumptions],range, Assumptions->something]. 
Moreover, the two sets of assumptions are quite unrelated and often 
another Simplify is needed at the end to get the answer in the desired 
form. It seems to me obvious that a single Assumptions->  in Integrate 
ought to be sufficient. While Simplify is rather unpredictable and 
difficult to control by the user, it ought to be available to Integrate 
without the user having to insert it explicitly. In fact the assumptions 
mechanism in Integrate is so weak as to be almost useless in practice, 
and it should be possible to make it work much better even without 
discovering new algorithms etc. This mechanism is rudimentary and old 
(predating by a long time the much more reliable Assumptions in Simplify 
and FullSimplify) and it seem to me that the only useful function it 
performs is pointing the way to how things ought to work. (Integrate is 
one of the very few or perhaps the only function that returns answers in 
the form If[...], which is an ambitious and desirable approach, if it 
were only implemented a little better...)

>
> 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.
>
This is of true, quite except for the few cases of problems that are 
well known, have been around for a while and where it is pretty clear 
how they could be fixed. I was looking for a "good explanation" why it 
has not yet been done.

Andrzej Kozlowski



  • Prev by Date: RE: Colors
  • Next by Date: RE: Re: calculating the azimuth between two lat/lon's
  • Previous by thread: Re: Re: Functionality and Reliability
  • Next by thread: Re: Re: Re: Functionality and Reliability