Re: Output Precision Exploration
- To: mathgroup at smc.vnet.net
- Subject: [mg118496] Re: Output Precision Exploration
- From: Daniel Lichtblau <danl at wolfram.com>
- Date: Fri, 29 Apr 2011 07:36:01 -0400 (EDT)
Joseph Gwinn wrote: > In article <ip8o8c$piq$1 at smc.vnet.net>, > Rafael Dunn <worthless.trash.junk at gmail.com> wrote: > >> Mathematica 8.0.1.0, Mac OSX x86 >> >> In:= >> Log[173.5/173.5] >> >> Out:= >> -1.11022*10^-16 >> >> I expect an output of exactly 0. Although 10^-16 is small, it turned >> out to be the largest factor in a chemical equation I was attempting to >> compute. >> >> I discovered this is because Mathematica does not actually evaluate >> 173.5/173.5 = 1. The output is actually some number 0.9999999999... >> >> However, for most decimal constants x/x produces an exact output of 1. >> By entering a few decimals off the top of my head I also found 1733.5, >> 26.44, and 27.44 do not produce an output of 1 when divided by >> themselves. >> >> Why? I understand Mathematica's algorithms for working with decimals >> must make approximations, but why is there so much variance among >> decimal calculations? 173.49/173.49 = 1, while 173.5/173.5 != 1. >> Furthermore, I find: >> x=173.49999999999999 >> x/x = 173.5/173.5, with infinite precision. If you add or remove a >> single 9 to the end of x, this ceases to be true. >> >> Furthermore, this looks like a contradiction to me: >> >> In:= >> 173.5/173.5 = 1 >> Log[1] = 0 >> Log[173.5/173.5] = 0 >> >> Out:= >> True >> True >> False >> >> I have learned a lot about Mathematica's precision and approximation through >> the help documentation, but I still can not explain this or see how I can >> expect Log[x/x] = 0 for the sake of calculations on the 10^-16 scale. > > The computations are performed using 64-bit double precision floating > point numbers, as defined in IEEE Std 754. This is by definition a > finite-precision computation, and errors of order 10^-16 are to be > expected, and cannot be removed unless one goes to Mathematica's > arbitrary precision arithmetic, which is orders of magnitude slower to > compute. > > You may wish to reformulate your problem. With an explanation of what > you are trying to solve and why, people will be able to suggest > alternatives. > > Joe Gwinn I will add a modest detail. (Nothing wrong with the above, just wanted to point out the underlying Mathematica semantics issue.) 173.5 is exactly representable as a machine float. Were this done as a pure division problem, I would expect to see a result of 1.0 for 173.5/173.5. In actual fact (as some I believe have observed) the quotient is parsed and interpreted as 173.5*(173.5^(-1)). First the reciprocal is computed. After which, we get a small departure from unity in the multiplication step, due to roundoff error. Daniel Lichtblau Wolfram Research