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: [mg31619] Re: [mg31604] Re: Zero does not equal zero et al.
  • From: David Withoff <withoff at wolfram.com>
  • Date: Sun, 18 Nov 2001 06:29:01 -0500 (EST)
  • Sender: owner-wri-mathgroup at wolfram.com

> Hello,
> Well, there is definitely something wrong.  Perhaps WRI can explain what is
> going on in the following notebook (v4.1, Windows).
> 
> There are two blocks of statements; I have commented where I think the
> results are wrong -- they are certainly inconsistent.  I prefer the output
> from the second block; except for the first True, it gives what I would
> expect and recommend.

Your examples are illustrations of how numerical error works,
and in particular that taking numerical approximations at the start
of a calculation cannot (except by accident) give the same result
as taking numerical approximations at the end of a calculation.
These are basic mathematical effects that have nothing to do
with Mathematica.

Consider, for example, the task of multiplying 1/3 by 2 in a system
based on arithmetic with four decimal digits.  The best four-digit
approximation to 1/3 is 0.3333, and multiplication by 2 gives 0.6666.
If one instead multiples 1/3 by 2 exactly to get 2/3, the best
four-digit approximation to that result is 0.6667.  These results
differ in the last digit.  In general, the results can differ by
an arbitrarily large amount.

Your examples are demonstrations of this effect.  For example:

\[Epsilon] = 1.0 10^-16; (* float*)
num = 145/247;
num2 = num + \[Epsilon];
num \[Equal] num2
num^83 \[Equal] num2^83
num^84 \[Equal] num2^84

compares the numerical approximation of the exact result num^84
with num2^84, where the approximation is done at the beginning,
in defining num2, rather than at the end. These results will always
(except by accident) be different.  Whether the results are considered
equivalent will depend on how the numerical errors work out and
on how the equivalence testing is done.  It is not mathematically
possible to design these things so as to never show behaviors that
you are apparently concerned about.

The point is that these are mathematically unavoidable effects which
will always be present in some form in all systems.  Furthermore, since
the underlying issues permeate essentially all of numerical computation,
anyone who uses inexact numbers really ought to take the time to
familiarize themselves, at least at some some rudimentary level, with
these effects.

> Concerning === versus ==, it's very inconvenient to use === in tests
> involving symbols because it gives False too often; it is only occasionally
> appropriate.

For example?

> As things now stand, I'm forced to use it to get the results I
> need for approximate numbers.  This compels me to make a tedious distinction
> in my code between purely symbolic and numerical quantities.  Shouldn't
> Mathematica be able to integrate the two without putting this burden on the
> programmer?

Inexact numerical quantities have fundamentally different mathematical
characteristics than exact or symbolic quantities. Even seemingly elementary
identities, such as commutativity and associativity of addition, are not
satisfied by inexact numbers except within numerical error.  If those
fundamental mathematical differences affect your calculations, then you do
indeed have to make appropriate allowances for that basic mathematics in your
programs, and there isn't anything that Mathematica or any other system can
do about it.  Computers are not immune to the laws of mathematics.

> What I meant by pattern matching is that a rule such as x_
> f[y_]:> y Sin[x] /; y == z may involve Equal.  So problems with ==  *do*
> affect the operation of rules.

By that definition everything in Mathematica affects the pattern matcher,
since a Condition pattern can invoke anything.

> I think the results show that Mathematica's behavior has become
> schizophrenic due to pollution from the floating point side.  Much valuable
> work has been done on both the numeric and symbolic aspects of Mathematica,
> but more thought needs to be given as to how the two pieces are going to fit
> together, both in terms of correctness and in terms of how programmers will
> ultimately use Mathematica.

Certainly calculation with inexact numbers is in some sense a messier
area of mathematics than calculation with exact or symbolic quantities.
That "pollution", however, is just the nature of the mathematics.
Mathematica is not going to stop doing correct mathematics just because
the mathematics doesn't work out as someone might have expected.

Dave Withoff
Wolfram Research



  • Prev by Date: Re: No joy using gcc 2.95.3 + MathLink v3r9 + Windows 2000
  • Next by Date: problem entering text
  • Previous by thread: Re: Zero does not equal zero et al.
  • Next by thread: Re: Zero does not equal zero et al.