MathGroup Archive 2011

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

Search the Archive

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



  • Prev by Date: Re: Workaround for Plot[ ] and color via PlotStyle
  • Next by Date: Re: Postfix specification graphics, etc.
  • Previous by thread: Re: Output Precision Exploration
  • Next by thread: Re: Short-cut for reiteration. Concise, readable symbols and