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

**RE: Colors**

**RE: Re: calculating the azimuth between two lat/lon's**

**Re: Re: Functionality and Reliability**

**Re: Re: Re: Functionality and Reliability**