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