Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2001
*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 2001

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

Search the Archive

Re: Re: Zero does not equal zero et al.

  • To: mathgroup at smc.vnet.net
  • Subject: [mg31693] Re: [mg31653] Re: Zero does not equal zero et al.
  • From: David Withoff <withoff at wolfram.com>
  • Date: Sat, 24 Nov 2001 16:44:10 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

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

Such "guesses" are part of all non-trivial functionality,
including IEEE standard arithmetic.  The fact that IEEE
standard arithmetic, or the default behavior of any system,
doesn't do what all users want all of the time, does not
mean that the designers guessed wrong.

IEEE standard arithmetic is based on the "guess" that many
users will tolerate mathematically ridiculous things, such
as a system that routinely makes up digits to pad results,
in exchange for efficiency.  For most applications this is
in fact a pretty good guess, which is the reason that
Mathematica uses IEEE standard arithmetic by default.

Variable-precision arithmetic in Mathematica is based on
the "guess" that it is also useful to have a system that
does automatic propagation of error -- things like keeping
track of the fact that multiplying a number with error dx
by 2 gives a result with error 2 dx, and so forth -- all
pretty basic stuff.

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

Mathematica is fully compatible with that advice, and
provides additional facilities, not available in machine
arithmetic, for keeping track of those errors.

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

It's just basic propagation of error.  It isn't terribly
elaborate.  It also isn't unique to Mathematica, nor is
it necessary to go to MathSource to find out about it. 
Propagation of error is discussed in high-school science
books and books on basic error analysis.  With a little
thought it's all fairly obvious.  And although keeping
track of error is slower than ignoring error, this doesn't
mean that ignoring error is standard.

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

Probably a better solution is to think a bit basic numerical
analysis and to use a strategy that is appropriate for the
task.  Both viable strategies (automatic propagation of error,
and arithmetic that ignores error for the sake of efficiency)
are available in Mathematica.

Dave Withoff
Wolfram Research


  • Prev by Date: RE: Aligning subplots nicely?
  • Next by Date: URGENT - Wavelets
  • Previous by thread: Re: Zero does not equal zero et al.
  • Next by thread: Dimensional analysis, Infinite sums