MathGroup Archive 2001

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

Search the Archive

Re: Zero does not equal zero et al.

  • To: mathgroup at
  • Subject: [mg31653] Re: Zero does not equal zero et al.
  • From: Richard Fateman <fateman at>
  • Date: Fri, 23 Nov 2001 05:46:24 -0500 (EST)
  • Organization: University of California, Berkeley
  • References: <9t86ia$r6r$>
  • Sender: owner-wri-mathgroup at

I think that the criticisms of numerical computation
in Mathematica that seems to pop up from time to time
in this newsgroup are mostly due to the attempt in Mathematica
to guess at what the user might want done, and sometimes
guessing wrong.

The straightforward advice often giving in numerical
computation books is that floating-point numbers should
not be tested for equality except in unusual circumstances,
and that
  relative error
   abs((x1-x2)/x1) < epsilon     [x1 not zero]

or absolute error
    abs(x1-x2) < epsilon

should be used instead.

If Mathematica had simply followed this advice, and otherwise
implemented the fastest possible arbitrary-precision arithmetic
then there would be another set of criticisms, but they
could be answered by saying

"we did it as fast as we know how"
"you can build slower stuff that keeps track of error on top
of this"
"if you want to understand what is going on, look in any of the
standard books.  E.g. see IEEE binary standard or radix-independent
standard arithmetic."

instead we see mathematica experts explaining

"we did this elaborate thing that you might not understand"
"if you want to understand it, read MathSource because it
is unique to Mathematica"
"it's slow, but if you want to use a standard model, you
can do so by making it even slower".

The solution though may be simply not to use Mathematica,
rather than trying to change Mathematica.


  • Prev by Date: Re: Sparse Matrix, Memory Allocation
  • Next by Date: RE: Log plots: plot points *linearly* equidistant
  • Previous by thread: Re: Re: Zero does not equal zero et al.
  • Next by thread: Re: Re: Zero does not equal zero et al.