MathGroup Archive 1996

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

Search the Archive

Re: Mathematica as a programming language.

  • Subject: [mg2983] Re: Mathematica as a programming language.
  • From: steiger at unixg.ubc.ca (James H. Steiger)
  • Date: 18 Jan 1996 05:16:16 -0600
  • Approved: usenet@wri.com
  • Distribution: local
  • Newsgroups: wri.mathgroup
  • Organization: The University of British Columbia
  • Sender: mj at wri.com

Mark Evans wrote an excellent summary of the strengths of Mathematica.

I concur with most of it.

However Mathematica as a programming language or system has
many weaknesses which Mark did not mention.

First, Mathematica has, in any release, many bugs. Many of them
are virtually inexplicable, given the description in one MathSource of
the alleged test process.

For example, one version for Windows could not print a cell that
was more than a page. I found the bug the day I took release of
the upgrade.  Hmmm..

My current version does not properly export the aspect ratio of
PostScript graphs. A note to Mathematica confirmed that this too was a
bug, and would be fixed in the "next release" which I have paid for
and have been waiting for over two years for.

These rather obvious bugs are never admitted with a tone of apology,
but rather a "who cares" attitude. I have never heard a Wolfram 
employee *apologize* for a bug that represents a fundamental
failure of a major system function. I know (as a software developer)
that major bugs will occasionally creep into the best of products, but
Wolfram has placed itself on a pedestal. Just read the hype in the 
Mathematica book.

As for the programming capabilities themselves, a major aspect of
any programming *system* is the editing and debugging capabilities.
Mathematica has debugging capabilities that are, well, Cro-Magnon.
That is, they are virtually non-existent. Numerous people have
asserted this, and I have never heard anyone debate it. When you 
are programming, it helps to have good debugging facilities.

As for the packages, many of them simply do not represent careful,
state of the art programming, and this is obvious to anyone who reads
them.  Often, the problems are left unfixed, and the user discovers
them at the worst possible moment, like after having invested hours of
thought and planning under the assumption that the function will work
as advertised.

For example, there is a statistics package for continuous
distributions. It includes the PDF (probability density function) and
the general function CDF(x), which is the integral of the probability
density function from minus infinity to x.  One distribution included
in the package is the NonCentral Chi-square distribution. The CDF 
function (inexplicably) is "not implemented" for this rather smooth 
function. Neither is quantile calculation. No explanation is given. 

However, if you try to numerically
integrate this function, you discover Mathematica does not appear to
be able to do it. At the same time, you discover why the Mathematica
book is best described as a user's guide and not a manual, as it is 
difficult to obtain any clue from documentation or error messages 
why this operation fails to work.  If you plot the PDF of the
NonCentral Chi-square, you see no obvious reason why Mathematica
should have much difficulty numerically integrating it. 

Such is frequently the case with Mathematica. Slick appearance can 
give way to slipshod reality.

Overall, it is a product well worth having, in my opinion. It has done
wonderful things for me on occasion. But, for someone used to full 
debugging capabilities and well-checked system functions, it can
offer some "interesting" surprises that, well, don't quite agree with 
the slick typesetting and marketing hype.







  • Prev by Date: Re: Mathematica as a programming language.
  • Next by Date: NIntegrate
  • Previous by thread: Re: Mathematica as a programming language.
  • Next by thread: Simplifying=> Sqrt[Meter^2/Second^2]